How to Run a TradingView Strategy on a Real Exchange

This is the full pipeline for taking a Pine Script strategy from backtest to live orders, without hand-waving. We'll cover what TradingView actually sends, what a receiving service must do with it, the two requirements that silently break people, and the checks you need before real money is involved.

What TradingView actually does with your alert

A TradingView webhook is just an alert notification. When the alert fires, TradingView sends an HTTP POST to the URL you configured, with the alert message as the request body. It does not retry, and it does not guarantee delivery.

The official Webhook-URL help doc spells out the constraints most people run into:

• Only ports 80 and 443 are accepted — a self-hosted service on another port must sit behind a reverse proxy.
• If your server takes more than about 3 seconds to respond, the request is cancelled. Persist the signal, return fast, process async.
• IPv6 is not supported.
• If the message is valid JSON, the request carries an application/json content type; otherwise it's text/plain. Receivers that only parse JSON need you to format the message as JSON.
• TradingView explicitly warns webhooks can occasionally fail to reach the URL, and tells you not to put credentials in the body.

The two requirements that silently break people

The placeholders that turn a template into a real signal

A static JSON template is useless — every ticker, side and size is different. TradingView substitutes {{...}} placeholders at trigger time. For strategy alerts the ones that matter are:

The receiving side needs the *previous* position, not just the target. Whether a signal is an open, an add, a reduce, a close or a reversal can only be told by combining direction, quantity, target state and previous state.

The middle layer: where the order actually happens

Between the alert and the order is a service that authenticates the signal, looks up your exchange credentials, reasons about your real position and calls the exchange API. You buy or build this layer.

• Build it yourself — full control, but you own the server, secrets, monitoring and idempotency.
• Exchange-native signal trading — some exchanges (Binance, OKX, Bybit) let you create a webhook signal in-app. Zero infrastructure, but fixed message format and parameters.
• A hosted bridge — a platform that receives your TradingView JSON and routes it to exchanges, plus the API-key management and logs.

Four checks before real money

1. Idempotency — send the same signal twice and confirm the position doesn't double. The receiver must query the exchange's actual position, not trust a local cache.
2. End-to-end latency — carry the trigger timestamp in the alert message, log receive-minus-trigger, and look at the P95 over a week, not the best case.
3. Reduce-only — a close signal that accidentally opens a reverse position is the classic 'blew up my account' bug. Confirm reduce-only semantics.
4. Key permissions — read and trade only, never withdraw; IP-allowlist your server's egress.

How AutoTrading fits

AutoTrading is the hosted-bridge route: you add exchange API keys, configure a bot (symbol, market type, leverage, position mode), and each bot gets its own webhook secret. You paste the bot's JSON template and webhook URL into your TradingView alert. The receiver authenticates against that secret, reads your *real* position on the exchange, and reasons open / add / reduce / close / reversal. Every signal is logged, and a paused bot ignores incoming signals.