Live Strategies API

Live strategies run approved strategy logic against current market data in paper or trade mode. The lifecycle service and live daemon, not the requested verb, own the effective state.

Operations

Conditional trade scope

The operation metadata lists the baseline research scope. Any live-start or confirmed mode-transition request whose requested mode is trade additionally requires the current key to have trade. The server checks this dynamically from the request body and rejects insufficient scope before activating runtime execution. Paper mode requires research only.

Trade mode requires owned account bindings for every execution exchange. It no longer uses an invitation or approval program. Paper mode creates isolated paper accounts and requires prospective initial_cash; initial_cash is rejected for trade mode. Active Paper and Trade strategy counts are enforced independently by the user's subscription plan.

Desired versus effective state

Pause, resume, and unsubscribe return:

• requested_action: what the caller asked for;
• effective_action: what the lifecycle service established;
• effective_status: the authoritative resulting state;
• reason: why the result differs, when applicable.

A resume can return an effective paused state when execution immediately fails and auto-pauses. Do not synthesize active from the requested verb. Read the subscription detail after every transition.

Confirmed mode switching can archive the old run and create a replacement subscription. Always replace local identity with replacement_subscription_id (or the returned effective subscription_id) and preserve previous_subscription_id for history. Compare requested_mode with effective_mode.

Unsubscribe coordinates daemon cleanup before archival. A retry after runtime teardown can finish the durable archive without repeating the teardown. Retry only the same subscription operation and verify the returned effective state.

Creation and activation

All new and existing strategy starts use POST /confirmation-intents. The action is either source_kind=inline with Signal DSL parameters or source_kind=existing with a strategy ID. Paper mode claims and executes the durable intent in the same request and returns user_action_required=false with the terminal execution and result. Trade mode returns user_action_required=true; the caller must show the server-provided risk summary and submit the opaque confirmation ID to the matching decision route.

Strategy preparation validates the selected live exchange, canonical universe, timeframe, Signal DSL, folder references, and account scope before daemon activation. A successful terminal result means the lifecycle service activated the subscription; failures are returned as durable failed operations rather than false active successes.

For fixed Polymarket markets, parameters.universe and DSL can use the market search result's strategy_ticker (POLYMARKET:<market_slug>). Orders explicitly select outcome='YES' or outcome='NO'; get_data(M) reads Yes by default and get_data(M, outcome='NO') reads No. A strategy that addresses outcome instruments separately can instead use the exact canonical tickers in the selected result's chart_sources. See Signal DSL for examples.

A live strategy may declare at most 20 universe symbols. This limit applies to cross-sectional and custom multi-symbol strategies; single-symbol and pair templates keep their own smaller shape-specific limits. The API validates the same limit used by the strategy creation UI.

Active runtime entitlements are mode-specific: Free includes one paper and no live runtime, Pro includes three paper and three live runtimes, and Ultra includes five paper and five live runtimes. Tick-level strategies require Ultra. See Subscription Plans for the complete public contract.

Use subscriptions/page for listing. It returns items, next_cursor, and total_count; fetch detail only for selected items and use documented expand values when settings or trades are needed.

Signals and webhooks

GET /v1/live-strategies/signals requires subscription_id even though it is a query parameter. Historical and latest endpoints are subscription-owned. Realtime clients must obtain a short-lived signed stream ticket and connect to the returned stream URL; the ticket is not an API key.

Webhook secrets sign delivery payloads. Store them as credentials, accept only HTTPS endpoints under the OpenAPI validation rules, and use the test operation before relying on signal delivery.