TradingView Alerts to Broker: How Webhook Trade Automation Works

What TradingView Webhook Automation Actually Is

TradingView webhook automation is a chain: a Pine Script alert fires, TradingView sends an HTTP POST with your alert message to a URL you control, and something at that URL turns the message into a broker order. TradingView itself never places the trade. It only delivers the message.

Per TradingView's help center, the POST body is your alert message verbatim. If the message is valid JSON, the request carries an application/json content type; otherwise it is sent as text/plain (TradingView, "How to configure webhook alerts"). Everything downstream, from parsing the payload to sizing the order to talking to the broker API, is your job or a vendor's.

The full pipeline has five hops:

1. Pine Script strategy or indicator evaluates a condition on each new tick of the realtime bar.
2. Alert is created on that script, with "Webhook URL" enabled under Notifications.
3. Webhook POST leaves TradingView's servers with the alert message as the body.
4. Bridge (a hosted service like TradersPost or PickMyTrade, or your own Flask/FastAPI endpoint) receives the POST, validates it, and maps it to an order.
5. Broker API accepts the order and returns a fill, a rejection, or nothing.

Each hop can fail independently. That is the central thing to understand before automating a TradingView strategy: you are wiring together three systems (TradingView, the bridge, the broker) that do not share state.

Which TradingView Plan Includes Webhooks

Webhook notifications are a paid feature. TradingView's plan comparison lists "Webhook notifications" under Alerts alongside per-tier alert caps (TradingView pricing page, read September 2026). Bridge vendors that depend on the feature document Essential as the minimum tier: PickMyTrade's plan guide and TradersPost's webhook article both state that the free Basic plan cannot send webhooks and Essential or higher is required.

Alert limits from the same pricing table:

Two practical consequences. First, an automated strategy needs a technical alert, not a price alert, so the free plan's 3 price alerts do not help. Second, Essential and Plus alerts expire after 2 months, which means a live bot on those tiers goes silent every 60 days unless you recreate the alert. TradingView lists Essential at $14.95/month or $12.95/month billed annually (TradingView pricing page, September 2026). Prices and caps change; confirm on tradingview.com/pricing before you build.

Two more requirements from the same help page: webhook alerts are only allowed when two-factor authentication is enabled on your TradingView account, and the destination URL may only use port 80 or 443.

The Alert Message: JSON Payload and Placeholders

The alert message is a free-text box. Whatever you type is the POST body. To make it machine-readable, write valid JSON and use TradingView's double-curly-brace placeholders, which are replaced with live values when the alert fires.

From TradingView's placeholder reference ("How to use a variable value in alert"):

A minimal strategy payload:

{
  "secret": "REPLACE_WITH_LONG_RANDOM_TOKEN",
  "symbol": "{{ticker}}",
  "action": "{{strategy.order.action}}",
  "price": {{close}},
  "bar_time": "{{time}}",
  "fired_at": "{{timenow}}",
  "interval": "{{interval}}"
}

Three details matter here. The strategy.* placeholders only work on alerts created from a strategy, not an indicator; on an indicator alert they arrive as literal text and break your JSON. The {{close}} value is the triggering bar's close, which on an intrabar trigger is not the last traded price. And TradingView's help page warns explicitly not to put login credentials or passwords in the webhook body. A random shared secret that only authorizes the endpoint is the standard compromise; it should never be a broker key.

For strategy alerts specifically, TradingView runs a copy of your strategy on its own servers. Changing the strategy on your chart does not update that copy. You must delete and recreate the alert (TradingView, "Strategy Alerts"). The same page notes that a strategy alert is stopped automatically if it triggers more than 15 times in 3 minutes.

Bridge Options Compared

You have three ways to receive the POST. The comparison below uses vendor-published figures as of September 2026; check each vendor for current pricing.

Hosted bridges remove the "keep a server up" problem and add position tracking and dashboards. They also add a fourth party with its own outages and its own copy of your broker credentials. Self-hosting removes the middleman but hands you every failure mode in the next section. A full breakdown of the first option is in the TradersPost review.

A Minimal Self-Hosted Endpoint (Python)

This example receives the payload above, checks the secret, enforces a max order size, dedupes on an idempotency key, and submits a market order to Alpaca's paper API. It is educational code, not production code, and it is missing position sync and a kill switch on purpose so those gaps are visible.

import hashlib
import os
import secrets

import httpx
from fastapi import FastAPI, HTTPException, Request

app = FastAPI()
SECRET = os.environ["TV_WEBHOOK_SECRET"]
ALPACA = "https://paper-api.alpaca.markets/v2/orders"
HEADERS = {
    "APCA-API-KEY-ID": os.environ["APCA_API_KEY_ID"],
    "APCA-API-SECRET-KEY": os.environ["APCA_API_SECRET_KEY"],
}
MAX_QTY = 10
SEEN: set[str] = set()  # replace with Redis or a DB table in real use


@app.post("/tv")
async def tradingview(req: Request):
    body = await req.json()
    if not secrets.compare_digest(str(body.get("secret", "")), SECRET):
        raise HTTPException(status_code=401)

    action = body["action"]
    if action not in ("buy", "sell"):
        raise HTTPException(status_code=400, detail="unknown action")

    # One order per symbol per bar. Same bar_time + action = same order.
    key = hashlib.sha256(
        f"{body['symbol']}|{action}|{body['bar_time']}".encode()
    ).hexdigest()[:32]
    if key in SEEN:
        return {"status": "duplicate_ignored"}
    SEEN.add(key)

    order = {
        "symbol": body["symbol"],
        "qty": str(min(int(body.get("qty", 1)), MAX_QTY)),
        "side": action,
        "type": "market",
        "time_in_force": "day",
        "client_order_id": key,
    }
    async with httpx.AsyncClient(timeout=2.0) as client:
        r = await client.post(ALPACA, json=order, headers=HEADERS)
    return {"status": r.status_code, "alpaca": r.json()}

Two constraints drive the design. TradingView cancels the request if your server takes longer than 3 seconds to respond (TradingView help center), so the broker call runs with a 2-second timeout and nothing slow happens before the reply. And client_order_id is passed to Alpaca so a retried POST maps to the same broker order; Alpaca exposes a lookup-by-client-order-id endpoint for exactly this reconciliation (Alpaca API reference). Alpaca setup, keys, and paper vs live URLs are covered in automating stock trading with Alpaca.

Failure Modes You Will Hit

Every one of these shows up in production. Plan for them before the first live order.

A worked example of delay and slippage

Hypothetical numbers. A 5-minute momentum alert fires at bar close with {{close}} = $100.00. The webhook arrives 30 seconds later. Your bridge submits a market order for 10 shares and fills at $100.18. Ten minutes later the exit alert fires at $101.20; the fill lands at $101.04.

• Backtest gross profit per share: $101.20 - $100.00 = $1.20
• Realized profit per share: $101.04 - $100.18 = $0.86
• Round-trip cost of delay plus slippage: $0.34 per share, or 28% of the modeled edge

On 10 shares that is $3.40 lost per trade. At 40 trades a month, $136. If the strategy's modeled expectancy was $1.20 per share, it is now $0.86, and a strategy that only cleared $0.40 per share in the backtest would be losing money live. This is why a hard MAX_QTY cap and a paper trading phase come first: the numbers you saw on the chart are not the numbers the broker will give you.

Safety Checklist Before Going Live

Work through this list in order. Each item removes a class of loss.

1. Paper first, for weeks. Point the bridge at a paper account until you have at least one full cycle of alert expiry, a market holiday, and a weekend gap. The paper trading guide covers what to log.
2. Secret token in the payload. A long random string checked on every request. Rotate it if it ever appears in a screenshot. Never put a broker key in the alert message.
3. Idempotency key. Hash symbol, action, and bar time. Pass it as the broker's client order ID. Reject repeats.
4. Max order size, enforced server-side. Cap quantity and notional in the bridge, not in Pine Script. TradingView cannot see your account.
5. Position check before every order. Ask the broker what you hold. Refuse orders that would double a position or flip it unintentionally.
6. Respond in under 3 seconds. Acknowledge the POST, then do slow work after, or TradingView will drop the request.
7. Kill switch. One environment variable or one endpoint that makes the bridge return 200 and do nothing.
8. Fill logging. Store alert price, submit time, fill price, and fill time for every order. Without this you cannot measure the slippage in the example above.
9. Recreate the alert after every strategy edit. The server-side copy does not follow your chart.

How Tradewink Handles This

Tradewink is not a TradingView-to-broker bridge and has no Pine Script integration. It does not place orders from TradingView alerts. Its own engine evaluates market data and can publish currently enabled signals rather than routing orders from a third-party chart. Its Paper Autopilot (Tradewink's public offering is paper trading only) goes through the same kinds of risk checks a self-hosted bridge would have to reimplement: position limits, per-order size caps, and per-user paper broker keys stored encrypted. If you would rather build the whole stack yourself, how to build a trading bot walks through the same layers without TradingView in the loop.

Automated execution of any kind can lose money faster than manual trading, and a webhook pipeline adds delay, duplicate, and desync risks on top of market risk. This article is educational and is not financial advice.