TradingView webhook order bridge: example scenario

This page does not describe a real client project. It is an example scenario that shows how Fincode approaches this kind of work. Technical details are based on official documentation; scope, timeline and price are set for each project.

Project summary
Who it is for	Individual trader who wants to automate Pine Script strategies on their own exchange account (example scenario)
Service	TradingView automation
Platforms	TradingView (a plan that includes webhook notifications), the client's own exchange account with API access
Technologies	HTTPS webhook receiver, durable queue, exchange REST and WebSocket APIs, Telegram and email notifications
Deliverables	Bridge software, alert templates, risk rules, audit log, test report, operations runbook

The need

The trader runs Pine Script strategies on TradingView and places each trade on the exchange by hand. TradingView alerts do not place orders themselves: when an alert fires, TradingView sends a POST request to a chosen URL, and the software listening there places the order. As of October 2026, webhook alerts require two-factor authentication, and TradingView's pricing page shows which plans include webhook notifications.

The goal is to remove the manual step while controlling three risks: forged or replayed requests turning into orders, the same alert being executed twice, and a faulty alert opening an unbounded position. Which exchange can be used depends on the client's jurisdiction and the exchange's terms; under Article 99/A of Turkish Capital Markets Law No. 6362, foreign crypto-asset platforms may not serve residents of Türkiye. Payload details are in TradingView alert message JSON.

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.

Solution architecture

A thin receiver accepts alerts and a separate worker executes orders, because of a hard deadline: as of October 2026, TradingView cancels a webhook request if the remote server takes longer than three seconds to process it.

Alert template: the Message field holds valid JSON, so TradingView sends it with an application/json content type. The template carries the shared secret, the symbol ({{ticker}}), the side ({{strategy.order.action}}), the quantity ({{strategy.order.contracts}}), the strategy position ({{strategy.position_size}}) and an alert ID built from {{ticker}}, {{interval}}, {{strategy.order.id}} and {{time}}, plus the firing time ({{timenow}}).
Receiver: listens for HTTPS on port 443 only; TradingView delivers webhooks to ports 80 and 443 and does not support IPv6. It checks the source IP, content type, secret and schema, writes the request to a durable queue and immediately returns a 2xx response.
Worker: takes the alert from the queue, checks whether that alert ID has already been processed, applies the risk rules and rounds price and quantity to the exchange's symbol rules (tick size, step size, minimum notional).
Order: the order is sent with a client order ID derived from the alert ID. On Binance this is newClientOrderId, and a new order with the same ID is rejected unless the previous one has filled. Fills are tracked through the user data stream or a REST query.
Logging and notification: every request is logged with its body, timestamp, decision and exchange response; the outcome goes to Telegram or email.

Security and risk controls

Verifying the request

Shared secret: the message includes a long random value known only to the bridge, compared in constant time. TradingView asks users not to put credentials such as passwords in the webhook body; this value is never an exchange API key and is rotated periodically.
Source IP: as of October 2026, TradingView sends webhooks from four IP addresses published on its help page. The receiver accepts only those and rechecks the list regularly, since it can change.
Client certificate: over HTTPS, TradingView also presents an SSL certificate. The receiver requests it via mutual TLS, validates the chain and checks O = TradingView, Inc. and CN = webhook-server@tradingview.com.
Stale alerts: if {{timenow}} is older than a threshold the client sets, the alert is rejected and logged.

Duplicate protection

If the receiver returns a status between 500 and 599 (except 504), TradingView resends the notification after 5 seconds, up to three times, so one trigger can arrive four times. The receiver therefore returns 2xx once the request is queued, and the worker never processes the same alert ID twice. The exchange adds its own ambiguity: per Binance's documentation, after a 5xx response the execution status is unknown and the order may have succeeded, so the worker queries it by client order ID (origClientOrderId) instead of resending.

Risk rules

Rule	Purpose
Symbol allowlist	Reject unexpected symbols caused by a template error
Maximum order size and position	Stop a malformed quantity from becoming a large order
Daily trade count and daily loss limit	Contain a looping alert or a bad day
Position reconciliation	Halt and notify if the strategy position and the exchange position disagree
Kill switch	Stop all new orders in one step

The exchange API key has read and trade permissions only, withdrawals stay disabled and the key is restricted to the server's IP address; on Binance, HMAC keys without an IP restriction cannot hold any permission beyond reading. Keys and the shared secret live in a secrets vault with audited access, never in source code; the OWASP Secrets Management Cheat Sheet advises against environment variables and calls for immediate revocation of exposed keys (see API key security for trading bots).

Testing and go-live

Logging endpoint: the receiver first only records requests, so the body, content type and placeholders can be inspected; the test URL must be publicly reachable.
Order validation: Binance's POST /api/v3/order/test creates and validates an order without sending it to the matching engine, which catches signature and symbol-rule errors early.
Testnet: the full flow runs on a test environment such as the Binance Spot Test Network, where balances are virtual and the network is reset periodically; its fills may not reflect live-market liquidity, so fill prices are not evaluated.
Failure scenarios: four deliveries of the same alert, an exchange returning 5xx, a late alert, invalid JSON and an oversized quantity are simulated, each with its expected behavior documented.
Controlled go-live: the live account starts with small position limits; strategy orders are compared with exchange fills, and the alert log's Webhook status column shows delivery results.

Bridge tests verify the delivery chain, not the strategy, which is backtested and paper traded beforehand (see how a TradingView webhook bot works).

Deliverables

Bridge software (receiver and worker) with source code and deployment scripts
TradingView alert message templates and, if needed, alert_message changes in the Pine Script code
Risk rules configured with the client's own limits, plus a kill switch
Audit log and Telegram or email notifications
Testnet and failure-scenario report
Operations runbook covering secret rotation, key revocation and IP list updates

With several accounts or exchanges, one alert is processed per account using position sizes set by the client (see TradingView automation).

How success is measured

Success is judged by how the bridge behaves, not by profit: strategy and investment decisions belong to the client, and automated orders can lose money. The evaluation criteria are:

No more than one order per alert ID across all test scenarios
Receiver response time measured and kept well under the three-second limit
Every alert, including rejected ones, logged with the reason for the decision
Logs that prove risk rules ran before every order
Every difference between strategy orders and exchange fills reported and explained

Frequently asked questions

Does the bridge work when my computer is off?

Yes. Alerts run on TradingView's servers and the bridge runs on a separate server, so your computer does not need to be on.

What happens if the same alert arrives twice?

The bridge is designed not to open a second order. Because TradingView can resend a notification up to three times after a 5xx response, the bridge stores each alert ID and never processes the same ID twice.

Can I put my exchange API key in the webhook message?

No. TradingView asks users not to send credentials in webhooks. The message carries only a separate secret known to the bridge; the exchange key stays in the server's secrets vault and has no withdrawal permission.

How much delay is there between an alert and an order?

A delay of a few seconds can occur. For strategies that decide within seconds, a trading system that reads market data directly from the exchange API may be a better fit.

Sources

Planning a similar project?

Tell us the platform, what the software should do and your timeline in a short form; a written proposal follows the initial review. Fincode is a software company and does not provide investment advice, portfolio management or crypto asset services.

TradingView automation service Send a project brief