Live Execution

Read one of your runs by its id

Changed on

Owner only, addressed by runId directly rather than through its strategy: the run's own canonical identity, which is what POST/GET/DELETE .../live, GET /live and GET /live/public all hand out. Use it to re-read one specific run — including one you stopped long ago or that is no longer your strategy's most recent — without paging through GET /live.

Returns the same state as GET /strategy/{strategyId}/live (strategyId is the strategy's id, and stats is there too), plus updatedAtMs: when the run last changed, from any cause — a state change, a promotion, a parameter update, a stop. A refresh of stats is not a change of the run and does not move updatedAtMs. A run that is public is reachable by others through GET /live/public, never through this route.

get/live/{runId}

Request

  • Base URL: https://api.qtsurfer.net/v1
  • URL: https://api.qtsurfer.net/v1/live/{runId}
  • Auth: HTTP bearer

Path parameters

runIdstring required

The runId from POST/GET/DELETE .../live, from GET /live or from GET /live/public

Response

The run

strategyIdstring required

Unique identifier for a compiled strategy, derived from the source itself: the same code always yields the same id, for every caller. How much formatting the id ignores depends on the language — see POST /strategy for exactly which rewrites preserve it and which do not.

runIdstring required

This run's own id — its canonical identity for PATCH/PUT .../params and for GET /live/public.

namestring
descriptionstring
visibility'private' | 'public' required
stage'SANDBOX' | 'LIVE' required

A new run starts SANDBOX, a 24-hour trial in which it is compared against a second execution and checked for resource use and stability. A run that passes moves to LIVE automatically when the 24 hours are up. A run of a strategy that an earlier run of yours already took through the trial starts LIVE, unless you started it with sandbox: true.

statestring required

The run's health right now: STARTING (no runner has reported on it yet), RUNNING, LAGGING (behind the market data, usually while catching up; clears by itself), HUNG (stuck inside one strategy call for longer than allowed; clears when it returns), DEGRADED (its independent executions produced different signals), FAILED (refused, could not start or failed while running; reason says why) or STOPPED. LAGGING, HUNG and DEGRADED come and go on a running run. The set may grow: read an unknown value as a running run with something to look at. See the Live execution guide.

desired'RUNNING' | 'STOPPED' required

What you last asked for. state can lag this briefly after DELETE.

reasonstring

Why the run stopped or failed, when there is something to say; absent otherwise. It is never a stack trace or an internal message. Either resource: ... (the platform stopped the run for exceeding its resource allowance; the text says which limit) or one of a fixed set of sentences for a FAILED run: the strategy cannot consume the source type the run was started with, the run's definition was refused, the run could not start after several attempts, the strategy failed while processing data, the run lost its data feed, or the generic The run failed.. The set may grow: read an unrecognised sentence as a failure and do not parse it. A FAILED run usually stays desired: RUNNING until you stop it, and counts as active (409 on a new start, and toward your live-run limit) until then; one that can never run because its strategy cannot consume its source type is stopped by the platform itself (desired: STOPPED), so it holds no place.

paramsobject required
paramsVersioninteger required

Increments on every accepted PUT .../params call, including one that resends the current values.

relayboolean required

Whether this run's signals are relayed over the WebSocket channel described in the "Live execution" guide. It is the value requested at start, in either stage.

startedAtMsinteger required

Epoch milliseconds.

gateobject

The sandbox trial's promotion verdict. Absent for the whole 24-hour trial and present once it ends, so an absent gate means the trial has not finished. A run that started in LIVE without a trial has it from the start: the verdict of the earlier run it relies on, with inheritedFrom naming that run. passed is the verdict; the rest is diagnostic detail whose shape is not yet stabilized as public API: treat it as opaque.

warmFrominteger

The warmFrom in effect for this run, in seconds: the one requested when the run was started or, when none was, the one the platform chose (the distance from the run's start back to the start of the current 15-minute block, 0 to 900). It is never null. It is present on every run started since the field exists and absent from a run started before it existed. It never changes while the run exists.

updatedAtMsinteger required

Epoch milliseconds of the run's last change, from any cause. It only moves forward, so of two reads of the same run the one with the larger value is the newer.

Example response

{
  "strategyId": "6bsh31ikwkuivhtgcoa6s4",
  "sources": [
    {
      "venueType": "cx",
      "exchange": "binance",
      "segment": "spot",
      "instruments": [
        "BTC/USDT"
      ]
    }
  ]
}

Changes

  • 7c8376a76d0dRevision changes
    • warning

      removed the optional property //// from the response with the status

    • info

      added the optional property / to the response with the status

  • 35450004397dRevision changes
    • info

      added the optional property //// to the response with the status