How TradingView webhook alerts work, the four platform constraints that cause most failures, and how to build a receiver that does not lose messages.
A TradingView webhook sends an HTTP POST to a URL you control the moment an alert fires. It is the standard bridge between analysis on a chart and code running somewhere else, and most of the difficulty sits in platform constraints that are easy to miss.
This piece covers the setup, the four limits that cause most failures, and how to build a receiver that behaves. For the wider architecture a webhook feeds into, see how to build a trading bot.
When an alert condition is met, TradingView sends an HTTP POST to your URL with the alert message as the body. That is the whole mechanism.
The message can be plain text or JSON, and it can contain placeholders that TradingView substitutes at fire time. Common ones are the ticker, the close price, the timeframe and the exchange.
What matters is what the mechanism does not include. There is no delivery confirmation, no retry, and no queue. If your receiver is down or slow, the message is gone. Nothing on the TradingView side records that it failed.
That single property shapes every design decision in the rest of this piece. A webhook is the delivery layer for a systematic trading setup rather than the system itself.
These are the platform limits that produce webhooks which appear configured correctly and do not work.
Ports 80 and 443 only. A receiver running on port 8080 or 5000 will never be reached. During development this is why a local server appears silent, and why a tunnelling tool is normally used to expose it on a standard port.
A three second timeout. TradingView cancels the request if your receiver has not responded in time. A receiver that places an order before responding will exceed this whenever the exchange is slow. Respond first, then process.
Two-factor authentication is required. Webhook alerts are unavailable on accounts without it enabled. The option simply does not appear, which reads as a missing feature rather than a prerequisite.
JSON only when it parses. TradingView sets the content type to application/json only if the rendered message is valid JSON. A single unquoted placeholder produces plain text instead, and a receiver expecting JSON rejects it. Paste the final rendered message into a validator rather than the template.
Create the alert from the chart or from a strategy, then open the notifications tab and enable the webhook URL field.
The URL must be HTTPS on a standard port and reachable from the public internet. The message goes in the message box, and this is where the placeholders live.
A workable JSON message keeps every placeholder quoted:
{
"secret": "your-shared-secret",
"ticker": "{{ticker}}",
"action": "long",
"price": "{{close}}",
"time": "{{timenow}}"
}Set the trigger frequency deliberately. Once per bar close fires when the candle completes. Once per bar fires as soon as the condition is met inside the bar, which means it can fire on a candle that later closes without meeting the condition at all. That difference is the same problem as evaluating an indicator mid-candle, and it produces behavior no backtest anticipated.
Because there is no retry, the receiver has to be available and fast rather than clever.
Respond immediately. Validate the payload, write it to a queue or a table, return a 200, and do the real work afterwards. Anything that calls an exchange before responding is one slow API call away from a cancelled request.
Make handling idempotent. Duplicate fires happen, and so do retries from any intermediate service. Derive a key from the ticker and the bar timestamp, then check it before acting. Without this, one duplicate opens a second position.
Log every request as received, including the ones you reject. When something has clearly fired and nothing happened, the raw body is the only evidence available and it does not exist anywhere else.
Handle the empty and malformed cases explicitly. A receiver that throws on unexpected input still returns an error to TradingView, which does not care, and the message is lost either way.
The URL is a public endpoint that anyone can POST to, and it is not authenticated by anything TradingView provides.
Include a shared secret in the message body and reject anything without it. This is the common approach and it is the minimum.
Use an obscure path rather than a predictable one. It is not security by itself, but it removes the endpoint from casual scanning.
Validate everything in the payload against an allowlist. Ticker names, actions and sizes should all be checked against values you expect rather than passed through to an exchange call.
Rate limit by source. A legitimate alert fires on a schedule you know. Anything arriving faster than your alerts can fire is not your alert.
Most webhook setups carry entry and exit instructions. A webhook can also carry context, which is a different and quieter use.
Market regime is the state a market is in, described rather than predicted: trending, ranging, or bearish. A system that knows the current state can gate its own rules, blocking evaluation in conditions a rule was not built for.
RegimeLab sends a webhook when a tracked pair changes state, so the receiving system updates its stored state rather than acting on a signal. The classification runs on the 4-hour timeframe and a change is only accepted after three consecutive matching reads, which is what stops a threshold reading near 25 from producing a stream of state changes that are noise.
The practical difference is what the receiver does with the message. A signal webhook triggers an action. A state webhook updates a variable that other rules consult. The second one can only ever block, which is a much smaller surface to get wrong. Which rules depend on which state is covered in algorithmic trading strategies.
A webhook is a delivery mechanism. It carries no guarantees beyond best effort.
It does not confirm delivery. Nothing tells you the message arrived, and nothing on the sending side records that it did not.
It does not retry. A receiver that is down during an alert has permanently missed it, and the gap is invisible unless you are monitoring for silence rather than errors.
It does not make a rule work. A webhook fires whatever condition you configured, in whatever conditions the market happens to be in, which is why the state that condition assumes is worth carrying separately.
And it does not order anything. Two alerts firing close together can arrive in either order, so a receiver that assumes sequence will eventually be wrong. For the Python side of the receiver, see algorithmic trading with Python.
An HTTP POST that TradingView sends to a URL you control when an alert condition is met. The alert message becomes the request body, and it can contain placeholders that are substituted at fire time.
Webhook alerts require a paid plan and two-factor authentication enabled on the account. Without 2FA the webhook option does not appear at all, which is often mistaken for the feature being unavailable.
The four common causes are a non-standard port, a receiver taking longer than three seconds to respond, two-factor authentication not being enabled, and an alert message that does not parse as valid JSON.
An HTTPS endpoint reachable from the public internet on port 443 or 80. Local development servers need a tunnelling tool, since a receiver on port 8080 or 5000 will never be reached.
No. There is no retry, no queue and no delivery confirmation. If the receiver is down or slow, the message is lost and nothing records that it failed, so monitoring for silence matters more than monitoring for errors.
Include a shared secret in the message body and reject anything without it, use an unpredictable path, validate every field against expected values, and rate limit by source. The endpoint is public and TradingView provides no authentication.
Once per bar close fires when the candle completes. Once per bar fires as soon as the condition is met inside the bar, so it can fire on a candle that later closes without meeting the condition, producing behavior no backtest anticipated.