Live Execution

Stop this strategy's live run

Changed on

Requests a stop. The run winds down at its own next check-in rather than instantly — poll GET/PATCH .../live and expect state to remain RUNNING for a short window after desired flips to STOPPED. Calling this again on an already-stopped run is not an error; it returns the same (unchanged) state. A stopped run has no stream: its streamUrl, if it had one, stops working and is not in this response.

delete/strategy/{strategyId}/live

Request

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

Path parameters

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.

Example:6bsh31ikwkuivhtgcoa6s4

The id returned by POST /strategy

Response

Stop requested (or already stopped) — the run's current state

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.

Example response

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

Changes