TradingView webhook bot: from alert to exchange order

Short answer: A TradingView webhook bot is a small program that receives the HTTP POST request TradingView sends when an alert fires, checks that it is genuine, applies risk limits and places the order through the exchange's API. TradingView does not route alerts to an exchange account by itself, so the bridge, running on your own server, determines how reliable and how safe the whole chain is.

Most traders looking into TradingView automated trading already have an indicator or Pine Script strategy and want its alerts acted on without watching the chart. TradingView supplies the trigger and the message; everything after the HTTP request, from validation to order placement and logging, is software you build or commission.

This guide follows one alert to the exchange order, using the limits in TradingView's Help Center as of October 2026. Message templates are covered in the guide to TradingView alert message JSON, and related guides are collected under TradingView webhooks.

How does a TradingView webhook bot work?

A webhook bot is a chain of four parts, and only the first runs on TradingView.

Alerts run on TradingView's servers, so your computer can be off, but the bridge must run around the clock. TradingView's Help Center states that automated strategy trading with a brokerage account is not available yet (as of October 2026): a strategy that looks good in the strategy report places no real orders until a bridge exists. A worked example with notifications and an audit log is on the TradingView order bridge project page. What changes from one exchange to another is covered in connecting TradingView to exchanges.

TradingView's Terms of Use (opens in a new tab), read on 5 November 2026, describe alerts and webhooks as licensed for display use and prohibit using them for automated trading, including through third-party products or services. Read those terms and take legal advice before relying on this route; it is your agreement with TradingView.

TradingView webhook requirements and limits (as of October 2026)

TradingView documents a few hard limits that shape the bridge; all can change.

Two consequences follow. The endpoint cannot wait for an exchange before answering, because placing and confirming an order can exceed three seconds. And the body is the only content you control: the Help Center describes no custom headers or request signing, so authentication relies on a secret in the body, the source IP list and, over HTTPS, the certificate TradingView's webhook server presents (O = TradingView, Inc., CN = webhook-server@tradingview.com). TradingView also warns against putting credentials or passwords in the body; exchange keys stay on the bridge, with the trade-only permissions described in API key security for trading bots.

Which TradingView plan includes webhooks? Free tier, price and 2FA

TradingView webhook alerts need a paid plan: on the plan comparison read on 4 November 2026, the Webhook notifications row is crossed for the free Basic plan and ticked for Essential, Plus, Premium and Ultimate.

Prices change, so check TradingView's pricing page before relying on these. The plan pays only for sending the alert: the bridge server and exchange fees are separate. TradingView's webhook help page adds an account condition, read on the same day: webhook alerts are allowed only when two-factor authentication is enabled.

Designing the bridge: authenticate, acknowledge, then trade

The safest pattern does the minimum inside the HTTP request and leaves trading to a background worker.

1. TLS on port 443; plain HTTP would expose the secret.
2. Source filter: TradingView's published IP addresses, plus its certificate if your stack verifies client certificates.
3. Secret check with a constant-time comparison.
4. Schema validation: symbol allowlist, side, quantity, timestamp window.
5. Deduplication on an alert ID, written in one transaction with the queued order.
6. Queue and reply 200; the worker checks risk, trades and reconciles.

This tested, standard-library sketch covers steps 3, 5 and 6. It receives one alert four times and queues one order, with a deterministic client order ID the worker can use to look the order up after a timeout instead of resending it.

import hashlib, hmac, json, sqlite3

SECRET = b"replace-with-a-long-random-string"
db = sqlite3.connect("bridge.db")           # survives restarts; a worker reads outbox
db.execute("CREATE TABLE IF NOT EXISTS outbox (alert_id TEXT PRIMARY KEY, client_id TEXT, body TEXT)")

def handle_webhook(body: bytes) -> int:
    """Return the HTTP status for TradingView; must finish well inside 3 s."""
    try:
        msg = json.loads(body)
    except (ValueError, RecursionError):
        return 400                          # 4xx replies are not resent
    if not isinstance(msg, dict) or not hmac.compare_digest(
            str(msg.pop("secret", "")).encode(errors="replace"), SECRET):   # never stored
        return 401
    alert_id = msg.get("alert_id")
    if not isinstance(alert_id, str) or not alert_id:
        return 400
    client_id = "tv" + hashlib.sha256(alert_id.encode()).hexdigest()[:20]
    try:
        with db:                            # commits the row, or nothing
            db.execute("INSERT INTO outbox VALUES (?, ?, ?)", (alert_id, client_id, json.dumps(msg)))
    except sqlite3.IntegrityError:
        pass                                # duplicate: acknowledge, do nothing
    return 200                              # a worker places the order later

alert = json.dumps({"secret": SECRET.decode(), "alert_id": "BTCUSDT-60-Long-2026-10-24T14:00:00Z",
                    "symbol": "BTCUSDT", "side": "buy", "qty": "0.01"}).encode()
print([handle_webhook(alert) for _ in range(4)])    # same alert delivered four times
rows = db.execute("SELECT client_id FROM outbox").fetchall()
print(handle_webhook(b"not json"), len(rows), rows[0][0])

It prints [200, 200, 200, 200], then 400 1 tv79458334b0752b171814, on an empty database and again on a second run. The status codes are deliberate: TradingView does not resend after a 4xx reply but does after a 5xx other than 504. A bridge that queues an order and then fails with a 500 invites a second delivery, so the record and the queued order must be written in one transaction, or a crash between them loses the order. If that write fails, the framework answers 500 and the resend stores the row; tested with a forced database error, the resend returned 200 and left one row. The stored row leaves the secret out. A module-level SQLite connection suits this single-threaded sketch only: used from another thread it raises ProgrammingError, so a threaded server opens one per request, as the TradingView webhook Python receiver does.

Why duplicate protection cannot be left to the exchange

Exchange client order IDs help, but they do not make a bot idempotent on their own.

Binance's spot API describes newClientOrderId as unique among open orders and accepts a reused ID once the previous order is filled (as of October 2026). A market order fills almost at once, so a repeated request can double the position. Duplicates come from TradingView resends, two alerts on one strategy, frequencies such as once per minute that keep firing, and the bridge's own retries.

Deduplication sits next to the other pre-trade checks: maximum order size and notional, maximum position, daily loss limit, symbol allowlist and a one-step kill switch, covered in trading bot risk management.

Existing webhook bots: what they do and leave to you

The two open-source projects below cover the receiving end and leave the trading controls to you, so read what a project does before reusing it. They are named as facts read on 5 November 2026, in no order of merit and not as recommendations.

Neither README mentions deduplication, risk limits or reconciliation, which is most of the work described above. If a subscription tool supports your exchange and you do not need custom checks, it is usually cheaper. A custom bridge fits when your platform is not supported, when you need your own risk rules, or when you want the code, keys and server under your own control.

Repainting and bar-close alerts: will live alerts match the backtest?

Live alerts match the backtest only when they fire on confirmed data.

Indicator alerts with any frequency other than once per bar close can fire while the bar is forming, and a crossover that sent a webhook mid-bar can be gone by the close. TradingView's Pine Script documentation calls bar-close triggering the simplest way to avoid this repainting, at the cost of a later alert. Even bar-close alerts wait for the next bar's first trade, which can take several seconds on thin symbols; with no trade, for example after a session ends, the bar closes one minute late.

Strategy alerts have their own rules (as of October 2026):

• They fire only for orders the broker emulator fills in real time, never on historical bars, and several can arrive in one bar.
• Order fill alerts trigger at execution; alert() calls in a strategy run at bar close unless calc_on_every_tick is enabled.
• calc_on_every_tick, calc_on_order_fills and trailing orders can make alerts differ from the orders drawn on the chart.
• With process_orders_on_close, alerts still come after the close, so in session markets the real order may wait for the next open.
• An alert keeps the script and settings it was created with; recreate it after any change.

Pine's fill rules, and how to reproduce them elsewhere, are explained in converting Pine Script to Python.

Latency, missed alerts and position drift

A bridge needs monitoring, because TradingView says webhooks may occasionally fail to reach the specified URL.

• Latency. No delivery time is guaranteed. Webhook bots suit minute to daily bars, not strategies that depend on sub-second moves; those need market data straight from the exchange.
• Missed alerts. Compare the alert log's Webhook status column with the bridge's request log daily, and export the log as CSV before the 30-day deletion.
• Stopped or expired alerts. Alerts stop after too many triggers or at their expiration time, so watch for missing activity, not only errors.
• Position drift. A Pine strategy tracks a simulated position. Partial fills, rejected orders and manual trades make the account diverge, so size orders from the position the exchange reports, not from {{strategy.position_size}} alone.

Exchange rate limits, order queries and reconnects are covered in crypto exchange API integration.

How to test a TradingView webhook bot before going live

Test in stages, with the exchange side on a test network first.

1. Request logger. Send a test alert to a public HTTPS endpoint that records body, headers and arrival time; TradingView will not deliver to localhost or private addresses.
2. Payload check. Confirm the content type is application/json and every placeholder was filled.
3. Exchange testnet. Use a test network such as Binance's Spot Test Network (REST base https://testnet.binance.vision/api) or a test endpoint such as POST /api/v3/order/test, which validates an order without sending it to the matching engine.
4. Failure drills. Return a 500, stop the worker mid-order, send malformed JSON; each drill must end with exactly one position.
5. Small live size, with fills compared against the strategy's assumptions and the kill switch within reach.

Automation removes a manual step, not the risk. Automated orders can lose money, a wrong quantity executes as fast as a right one, and backtests do not guarantee future returns. Whether you may use an exchange depends on your jurisdiction and its terms; in Turkey, Capital Markets Law No. 6362 Art. 99/A treats activity by foreign crypto-asset platforms directed at Turkish residents as unauthorized. Building such a bridge is the scope of the TradingView automation service.

TradingView's Help Center says its alerts are not designed for automated trading (opens in a new tab) (read 4 November 2026), so a bridge has to handle late, repeated or missing alerts itself.

Frequently asked questions

Is the TradingView webhook feature free?

No. On 4 November 2026 webhook notifications were included in the paid Essential, Plus, Premium and Ultimate plans but not in the free Basic plan, and they require two-factor authentication on the account.

How much does a TradingView plan with webhooks cost?

On 4 November 2026 the lowest listed plan with webhook notifications, Essential, showed $12.95 a month billed annually or $14.95 at the regular monthly price. Prices change, so check TradingView's pricing page.

Can TradingView send orders to Binance automatically?

Not by itself. TradingView posts the alert message to your webhook URL, and a bridge you run places the order through the Binance API with a trade-only key; TradingView says automated strategy trading with a brokerage account is not available yet.

Why did my bot receive the same alert twice?

TradingView resends a webhook after a 500 to 599 response other than 504, up to three times, and duplicated alerts or repeating frequencies can send the same alert again, so store an alert ID for every message and ignore repeats. An ID built from {{strategy.order.id}}-{{timenow}} catches only TradingView's resends, because a second alert or a repeating frequency gets a new time and a new ID. To collapse repeats on one bar, use {{ticker}}-{{interval}}-{{strategy.order.id}}-{{time}}, which also blocks a genuine second fill of that order ID on the same bar.

Can I receive TradingView webhooks on localhost or a custom port?

No. Only ports 80 and 443 are accepted, IPv6 is not supported and URLs resolving to localhost or private IP addresses are rejected, so the endpoint must be publicly reachable, preferably over HTTPS.

Can an indicator drive the bot, or does it need a strategy?

Both work. Indicator alerts send the message you define, while strategy alerts can fill in order details such as {{strategy.order.action}} and {{strategy.order.contracts}} automatically.

Sources

• TradingView Help Center: How to configure webhook alerts (opens in a new tab)
• TradingView Help Center: Webhook resubmission (opens in a new tab)
• TradingView Help Center: What do errors mean when sending webhooks? (opens in a new tab)
• TradingView Help Center: Webhook authentication (opens in a new tab)
• TradingView Help Center: Alert name and message size limits (opens in a new tab)
• TradingView Help Center: Strategy alerts (opens in a new tab)
• TradingView Help Center: Mismatches between strategy alert triggers and strategy orders on the chart (opens in a new tab)
• TradingView Help Center: Delays in OncePerBarClose alerts (opens in a new tab)
• TradingView Help Center: How to autotrade using Pine Script strategies (opens in a new tab)
• TradingView Help Center: Automatic deletion of old alert triggers from the Log (opens in a new tab)
• TradingView: Plans and pricing (webhook notifications by plan) (opens in a new tab)
• TradingView Pine Script v6 User Manual: Alerts (opens in a new tab)
• TradingView Pine Script v6 User Manual: Strategies (opens in a new tab)
• Binance Spot API: Trading endpoints (newClientOrderId, test new order) (opens in a new tab)
• Binance Spot Testnet: General API information (opens in a new tab)

This guide is general information about software and markets, not investment, legal or tax advice. Automated trading can lose money, past or backtested performance does not guarantee future results, and the rules that apply depend on your jurisdiction and your exchange's terms. Sources, checks and corrections: see the editorial policy.