Skip to main content
Trading mutations use POST /v1/commands. The API accepts open, modify and terminate; the permission is selected by the action. Reads and template CRUD do not create trading-command receipts.

Command envelope

The request’s link and instrument must equal the envelope’s link and instrument. Ordinary API commands do not accept the TradingView source/lifecycle reference fields. Use a disciplined UTC clock. An unseen command must be issued within the five-minute admission window, with only the documented 30-second future-clock allowance, and must still be inside its own deadline. Expiry prevents new handoff; it is not an instruction to cancel an already executing position at that time.

Acceptance example

These IDs and dates are synthetic. New acceptance returns 202; an identical previously accepted intent returns 200 with its original receipt. The returned position UUID belongs to that single OPEN identity even if the first HTTP response is lost.

Idempotency is immutable intent

Persist the complete command before sending it. Retrying means retransmitting the same client command ID, timestamps, deadline, target and payload. Do not refresh timestamps or alter a quantity under the same ID. A different payload for an existing identity returns a conflict. A timeout does not prove absence of acceptance. Retry the exact immutable request or inspect receipts. If its outcome becomes unresolved, reconcile rather than generate a new OPEN or replay a whole modification. An expired retry of a known identity can return the original receipt; a new expired intent cannot be admitted. Credential rotation retains the namespace. A different independently created API integration has a different namespace; reusing the same client ID on a new namespace is not a retry of the first namespace’s command.

Receipt states

A termination receipt can include terminal_request_kind (1 close, 2 cancel) and terminal_request_seq. This records the durable terminal request; it does not certify completed venue cancellation or flat exposure. Receipt states do not replace position accounting.

Read and paginate receipts

GET /v1/commands returns up to 50 top-level namespace receipts with commands and a nullable next_cursor. Pass the returned cursor unchanged to read older receipts. Group children are not repeated in the list. Receipt detail can contain up to 64 child targets for a TradingView group. A same-account API key with read and the exact authorized link/instrument can inspect a known TradingView receipt UUID. That does not give it access to the TradingView namespace list or mutation identity. The Settings Activity tab lists account receipts and refreshes on demand.

Retention and recovery

Resolved receipts are retained for 30 days; unresolved work remains until resolution. Archive receipts needed for longer audit retention in your own system, without keys or raw secret-bearing webhook bodies. Recovery consults canonical position, lineage and terminal-request evidence. An uncertain modification is not replayed wholesale and no compensating trade is invented. A subsequent order fill can change position state after an earlier observation; check current exposure before issuing dependent work. Revocation and entitlement expiry block new handoffs. They do not interrupt protection, termination or recovery that already belongs to Liftx. Do not use credential revocation as an emergency close operation.