TradingView Webhook Payload Reference
A TradingView webhook is a single HTTP POST containing whatever text you put in the alert message box. TradingView imposes no schema — the payload is entirely yours to design, and your receiving endpoint defines what is valid. What TradingView controls is the transport: one attempt, no retry, three-second timeout, ports 80 and 443 over IPv4, and an application/json content type only when the message parses as valid JSON. Placeholders in double curly braces are substituted with live values at fire time.
The transport, precisely
Before payload design, the delivery guarantees, because they constrain what a sane payload looks like.
One POST per fire. No retry, no acknowledgement, no delivery guarantee beyond a single attempt. A non-2xx response, a timeout, or an unreachable endpoint means the signal is gone and TradingView does not report it.
Three-second timeout. Respond fast, process asynchronously. Acknowledging inside three seconds while broker calls continue behind the response is a high-concurrency I/O pattern rather than a scripting one.
Ports 80 and 443, IPv4 only.
Content type follows the body. Valid JSON produces application/json; anything else produces text/plain.
No signature. TradingView does not sign requests. There is no HMAC to verify, which means anyone who learns your URL can post to it. Authentication has to be something you put inside the payload.
Payload design
Since TradingView enforces no schema, the fields below are a convention rather than a specification. They are the ones a receiving endpoint generally needs.
secret — a shared secret your endpoint validates before doing anything else. This is your only authentication.
ticker — the instrument, usually from a placeholder.
action — what to do: buy, sell, close.
quantity — size. Consider whether your endpoint should trust this or compute it independently from your own risk rules.
order_type — market, limit, stop.
price — for limit and stop orders.
strategy_id — which strategy sent this, so one endpoint can serve several.
id — a unique identifier for this specific signal, used for deduplication.
A minimal entry payload:
{"secret": "your-shared-secret", "strategy_id": "dual-trend-spx", "action": "buy", "ticker": "{{ticker}}", "quantity": 1, "order_type": "market", "time": "{{timenow}}"}
A limit order adds a price:
{"secret": "your-shared-secret", "action": "buy", "ticker": "{{ticker}}", "quantity": 1, "order_type": "limit", "price": "{{close}}"}
A strategy alert carrying the strategy's own order details:
{"secret": "your-shared-secret", "action": "{{strategy.order.action}}", "ticker": "{{ticker}}", "quantity": "{{strategy.order.contracts}}", "position_size": "{{strategy.position_size}}", "order_id": "{{strategy.order.id}}"}
An exit:
{"secret": "your-shared-secret", "action": "close", "ticker": "{{ticker}}", "strategy_id": "dual-trend-spx"}
Note that placeholder values are wrapped in quotes even when they represent numbers. TradingView substitutes text, and an unquoted placeholder that resolves to an empty value produces malformed JSON — which silently flips the content type to text/plain.
Design rules that matter
Include an idempotency key. Because there is no acknowledgement, a duplicate or replayed request is indistinguishable from a genuine one. A unique per-signal identifier lets your endpoint reject a repeat rather than opening a second position.
Do not let the payload size the position. Or if it does, bound it server-side. A payload is user input arriving over an unauthenticated channel, and an endpoint that submits whatever quantity it is handed is one malformed alert away from a very large order. Compute size from your own capital rules and treat the incoming value as a suggestion.
Validate the secret first. Before parsing, before routing, before anything. Compare in constant time.
Keep it flat. Nested structures are harder to build reliably from a text template where a single missing brace breaks everything.
Log the raw body. Every request, before parsing. When something misbehaves, the raw payload is the only evidence of what actually arrived, and TradingView keeps no sending-side record you can inspect.
Security, given no signing
Worth stating plainly because the shared-secret pattern is often described as if it were equivalent to signing. It is not.
A shared secret in the body is a bearer token transmitted in full on every request. It proves the sender knew the secret. It does not prove the request is fresh, so an intercepted payload can be replayed verbatim. It offers no integrity guarantee. And the secret sits in your TradingView alert configuration, so anyone with access to that account can read it.
What you can do: use HTTPS without exception, use a long random secret, rotate it, add an idempotency key so replays are caught by deduplication rather than by cryptography, reject stale timestamps, and if your endpoint is on infrastructure you control, restrict inbound traffic to TradingView's published source addresses. Running the endpoint inside a self-hosted deployment makes that last control available in a way a shared multi-tenant service cannot offer, since the endpoint and its network policy are yours.
The honest limits
There is no official payload specification because TradingView does not define one. Anything presented as the standard format is a receiving platform's schema, and switching platforms means rewriting alerts.
Signal loss is designed in. One attempt, no retry. Build for missed signals rather than assuming delivery, which in practice means exits that must happen should rest at the broker rather than depending on a future webhook.
The three-second window means anything slow has to be asynchronous, which means your endpoint returns 200 before it knows the order succeeded. Acknowledgement is not execution.
And a correct payload is not a good strategy. Position sizing is the control that bounds loss — capital divided by twenty as the ceiling per position, under the divide-by-20 rule — and it is the one thing here that keeps working when a request never arrives.
Frequently asked questions
What format does a TradingView webhook use? Whatever you write in the alert message. TradingView imposes no schema. Valid JSON is strongly preferred because it determines the content type.
Does TradingView retry failed webhooks? No. One attempt per fire, no retry and no delivery guarantee.
Does TradingView sign webhook requests? No. There is no HMAC signature. A shared secret inside the payload is the common substitute and is weaker.
What is the webhook timeout? Three seconds. Acknowledge immediately and process asynchronously.
Which ports does TradingView send to? 80 and 443 only, over IPv4.
Should quantity come from the payload? Bound it server-side regardless. The payload arrives over an unauthenticated channel and should not be trusted to size a position.
Disclaimer: This article is educational content about software engineering and trading automation. It is not investment advice, financial advice, tax advice, legal advice, or a recommendation to buy or sell any security. Any instruments named are used solely to illustrate mechanics. Options trading involves substantial risk of loss and is not suitable for all investors. Please read Characteristics and Risks of Standardized Options before trading options. Automated trading systems carry additional risks including software defects, missed or duplicated signals, network and connectivity failures, third-party service changes and outages, and unintended order behaviour that may prevent orders from being placed, modified, or cancelled. Past performance does not indicate future results, and no configuration, alert setup, position-sizing rule, or risk setting can guarantee a profit or prevent a loss.
StaxInvesting LLC sells self-hosted trading software. It is not a broker-dealer, investment adviser, or financial institution, and it does not manage accounts, hold member funds, place trades on behalf of members, or access member brokerage accounts. Members run the software in their own cloud environment, connect their own brokerage accounts under their own credentials, and are solely responsible for their configuration, their credential security, their compliance with third-party terms of service, and every trade executed in their account. Third-party platform details described here reflect publicly available documentation as of publication and are subject to change without notice; always verify against current official documentation. Consult a qualified financial adviser and tax professional regarding your individual circumstances.