Receive a TradingView alert
Use the hooks host, valid JSON and exactly one nonnull alert or command.
Authorization
Restricted TradingView key in body token; ordinary API keys are invalid.Behavior
Use the hooks host, valid JSON and exactly one nonnull alert or command. No client-certificate setup is required. New durable acceptance returns 202; identical retry returns 200; temporary or inactive admission returns 503. The application admission budget is two seconds. Receipts are not execution feedback to Pine.JSON body example
The following shows the request shape, not live credentials or executable market defaults. Replace timestamps only when creating a new reviewed intent; never mutate them on a command retry.https://hooks.liftx.io/v1/tradingview/events, not the API host. This example assumes a guided setup that already stores the OPEN request. TradingView substitutes {{timenow}}; a direct sender must supply the canonical UTC timestamp itself.
Response and errors
The generated response schema below is the wire contract. Preserve fixed-point strings, nullable fields and endpoint-specific envelopes. Inspect HTTP status and Content-Type before decoding failures; reused trading routes may return JSON or plain text. Authentication, entitlement and exact link/instrument restrictions apply in addition to endpoint validation. See errors and recovery. Do not automatically repeat a mutation after transport ambiguity. Trading commands reuse the exact immutable identity; credential issuance and template writes require their documented metadata/read reconciliation. Read the related guide for lifecycle, units and recovery semantics.Body
- Option 1
- Option 2
Exactly one non-null command or alert object. The restricted body token authenticates either transport; both converge on the same canonical command admission.
Immutable source/revision and exact market. Each new OPEN uses a new lifecycle reference and sequence above the source watermark. Known-position termination remains per-reference ordered; groups freeze at most 64 targets and never reselect on retry. Advanced OPEN and MODIFY use the existing PositionRequest; capped MODIFY preserves OPEN rows. Pine has no execution-feedback channel.
Ordinary OPEN/EXIT alert pair. Guided OPEN omits request; advanced OPEN requires full canonical request. OPEN identity/reference are derived from source and fired second. Sequence is Unix milliseconds with termination ranked +1. One distinct OPEN and EXIT per second per setup; identical payload duplicates return original receipt, changed payload conflicts. EXIT has no exact lifecycle reference. Source authority, permissions, quantity cap, receipt and trading execution remain canonical. Do not mix this pair with a Pine producer.
Response
Identical accepted event
Durable command receipt, never a fill/completion assertion. Terminal request fields correlate a durable termination owner handoff. Terminal arm writes kind/sequence while retaining dispatching; owner return or startup canonical evidence advances handed_off. Group parent position_id is null. Precedence is operator_required, dispatching, accepted, then homogeneous resolved state or partial. Zero-target parent is execution_observed. Counts and child states do not prove exposure is flat.
accepted, dispatching, handed_off, execution_observed, rejected, expired, operator_required, partial 1, 2 x >= 1Parent group on a child termination receipt.
Counts sum to the immutable target_count. Zero targets records an observed empty selection, not market flatness.
Group detail only: at most 64 frozen ordinary termination receipts. Targets cannot contain nested groups or target arrays. Omitted on list responses and zero-target groups.
64