RealTest User Guide
RealTest User Guide

 

 

Navigation: Other Ways to Use RealTest >

Using the Automation API

 

 

 

 

RealTest can expose a local HTTP + JSON interface that lets scripts and AI tools drive a running RealTest window: run scripts, read results, send menu commands, capture screenshots, and more.

This is an alternative to Command Line Mode. Both run the same scripts and write the same output files; they differ in how RealTest is controlled.

Batch Mode or the API?

•Use batch mode for a single unattended run: a scheduled morning order generation, a nightly import, a shard of a large optimization, or a one-off test. Each run is a fresh process with an exit code and a batchlog.txt, and there is nothing to connect to or shut down afterwards.

•Use the API when the same instance will be asked to do several things: iterating on a script (loaded data and calculated Data columns stay in memory, so repeated tests skip the load and calculation phases and typically run several times faster), reading results without parsing CSV files, or getting parse errors back as structured line and column numbers rather than log text.

•Use the API for anything only the interactive window can do: Trade Plots and Factor Scan, Charts, Graphs, any menu command, and screenshots of those windows.

The AI research materials in the Research folder (see Using RealTest with Agentic AI) describe both approaches to the assistant and let it choose.

Enabling the API

The listener is off by default. Turn it on for every session in realtest.ini, or for one launch on the command line:

Setting

Default

Meaning

Api

0

in the [Options] section of realtest.ini; 1 starts the listener whenever RealTest starts with that ini file

ApiPort

7827

the TCP port to listen on (127.0.0.1 only); 0 picks any free port

ApiToken

(empty)

an optional secret; when set, every request must include it in an X-RealTest-Token header

-api

 

command line argument: enable the API for this launch regardless of the ini setting

-port N

 

command line argument: enable the API on port N (0 = any free port) for this launch

Neither argument puts RealTest into batch mode; the window opens normally and the API simply becomes available once startup is complete. If the port is already in use, RealTest logs the failure to errorlog.txt and runs without the API.

An automation script that launches its own RealTest should also pass -hide (start minimized without taking keyboard focus) and -inifile with a copy of realtest.ini, so that the driven instance saves its settings to the copy rather than to your own configuration. In that copy, set AskSaveUntitled, AskUnloadData, AskDeleteTests and ConfirmStop to 0 so no Yes/No prompt can appear.

realtest.exe -api -hide -inifile C:\temp\drive.ini C:\Scripts\myscript.rts

Finding a Running Instance

Each listening instance writes a small JSON file named after its process id to %LOCALAPPDATA%\RealTest\api\ with its port, URL, executable, ini file and start time, and deletes the file when it exits. A program that launched RealTest reads the file for its process id; a program attaching to an already running session lists the folder. Until the instance has finished starting, connections are refused, so retry until a GET /status request succeeds and reports state "idle".

How Requests Work

Requests are ordinary HTTP GET and POST calls to http://127.0.0.1:port, with JSON bodies and JSON responses. Every JSON response is either {"ok":true,"result":...} or {"ok":false,"error":{"code":...,"message":...}}. Tabular data (results, trades, stats) is returned as CSV text.

Requests that change the program state are carried out on the RealTest window thread in the order received, and each response is sent only when RealTest is idle again: no run in progress and no calculation still working. Callers therefore never need to wait or retry between steps. A request that arrives while a run is in progress is refused with a "busy" error rather than queued. Read-only requests such as status and log are answered immediately, even during a run.

A run request creates a job. By default the response waits until the job has finished; a "wait" value in seconds caps the wait, after which the response reports the job as still running and it can be polled. The job object reports success, the batch-mode exit code, every error message RealTest would have shown, structured parse errors (file, line, column, message), the tests it added (count and test-number range), the Results window that received them, and any modal dialog it is waiting on.

Requests

Request

Purpose

GET /status

run state, busy flag, active script, data file, status bar text, current job

GET /help

a machine-readable list of all requests

POST /open

open a file as File > Open would (script, results, CSV, trade list)

POST /run

run a script in a given mode (parse, test, optimize, import, scan, orders, apply), optionally with #define names for that run; an optimization runs without the Optimize dialog

GET /jobs, GET /jobs/{id}

remembered jobs, or one job (optionally waiting for it to finish)

POST /stop

request Stop for the running job, or dismiss a modal dialog that is holding it

GET /log

the Log window contents as numbered lines, or as plain text

GET /results

the Results window as CSV, the same columns as SaveTestListAs

GET /results/{n}/trades

the trade list of test n as CSV, in the Full layout by default or the Compact layout on request

GET /results/{n}/stats

the daily stats of test n as CSV, as SaveStatsAs writes it

GET /windows

the open child windows: id, class, title, active

POST /activate, POST /close

make a child window active, or close it

POST /select

select a row in a list window (a Results test by number, or any row by index) so that menu commands act on it

POST /command

send any menu command by its command id; returns when RealTest is idle again

POST /key

send a keystroke (arrow keys, Enter, F-keys, a character) or type text into a child window

POST /screenshot

capture a child window or the whole frame as a PNG file or image response

POST /exit

close RealTest gracefully

Menu commands act on the active child window and its selected row, exactly as they do when chosen from the menu, so activate the intended Results, Plot or Chart window (and select the intended row) before sending one. Commands that open file dialogs should be avoided; use /open and the script Save...As settings instead.

Security

The listener accepts connections only from the local machine (127.0.0.1). Programs running under your own Windows account already have the same access to your files as RealTest does, so the remaining concern is a web page in your browser making blind requests to localhost. Such requests are rejected: RealTest refuses any request carrying an Origin header, requires the Host header to name 127.0.0.1 or localhost, and requires POST bodies to be declared as JSON. If other user accounts share the computer, set ApiToken so that requests without the token are refused.

Error Messages and Prompts

While RealTest is carrying out an API request or job, and at all times in an instance launched with -api or -port, error message boxes are not shown. The text is returned in the job's messages and appended to batchlog.txt and errorlog.txt, so a driven instance never blocks on a message box. A session that merely has Api=1 in its ini keeps its normal message boxes for your own actions. Yes/No questions are still shown, which is why a driven instance should run with the Ask... and Confirm... options turned off in its ini copy. If one appears anyway, GET /status reports it (state "dialog", with the question text) and POST /stop dismisses it. The Optimize dialog never appears for a run started through the API: the optimization runs as if the script had OptNoDialog: True. Should RealTest crash, the request that was running is answered with a "crashed" error, GET /status reports state "crashed" with the crash report and the dump file's path, the log can still be read, and POST /exit closes the crash message box, which ends the process.

Learn More

The complete request reference, with every parameter and response field and working PowerShell, curl and Python examples, is realtest_api.md in the Research folder inside your RealTest installation (see Using RealTest with Agentic AI). It is written so that an AI assistant can read it and drive RealTest without further help.

 

 

 

Copyright © 2020-2026 Systematic Solutions, LLC