# TradingView webhook order bridge: example scenario

URL: https://fincodelabs.com/en/projects/tradingview-order-bridge · Publisher: Fincode (Fincode Yazılım ve Teknoloji A.Ş.), Istanbul, Turkey · Published: 2026-10-24 · Updated: 2026-10-24

In this example scenario, a trader running Pine Script strategies wants TradingView alerts to become orders on their own exchange account. The system is bridge software that verifies each webhook, drops duplicate alerts, applies risk rules before any order and logs and reports every step.

> 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](https://fincodelabs.com/en/blog/tradingview-alert-message-json).

TradingView's [Terms of Use](https://www.tradingview.com/policies/), 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.

1. **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}}`).
2. **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.
3. **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).
4. **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.
5. **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](https://fincodelabs.com/en/blog/api-key-security-trading-bots)).

## Testing and go-live

1. **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.
2. **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.
3. **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.
4. **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.
5. **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](https://fincodelabs.com/en/blog/tradingview-webhook-bot)).

## 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](https://fincodelabs.com/en/services/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

- [TradingView: How to configure webhook alerts (ports, IPs, three-second timeout, content type, 2FA)](https://www.tradingview.com/support/solutions/43000529348-how-to-configure-webhook-alerts/)
- [TradingView: Webhook resubmission](https://www.tradingview.com/support/solutions/43000735201-webhook-resubmission/)
- [TradingView: Webhook authentication (certificate fields)](https://www.tradingview.com/support/solutions/43000680459-webhook-authentication/)
- [TradingView: How to use a variable value in alert (placeholders)](https://www.tradingview.com/support/solutions/43000531021-how-to-use-a-variable-value-in-alert/)
- [Binance Spot API: REST API (limits, 5xx and unknown execution status, test order, newClientOrderId)](https://github.com/binance/binance-spot-api-docs/blob/master/rest-api.md)
- [TradingView: Plans and pricing (Webhook notifications)](https://www.tradingview.com/pricing/)
- [Binance Spot Test Network](https://testnet.binance.vision/)
- [Binance: How to create API keys (IP restriction and permissions)](https://www.binance.com/en/support/faq/how-to-create-api-keys-on-binance-360002502072)
- [OWASP Secrets Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html)
- [Capital Markets Law No. 6362, Article 99/A (Turkish)](https://www.mevzuat.gov.tr/mevzuatmetin/1.5.6362.pdf)
- [TradingView: Terms of Use (read 5 November 2026)](https://www.tradingview.com/policies/)

---

Published by Fincode (Fincode Yazılım ve Teknoloji A.Ş.), a software company in Istanbul, Turkey: https://fincodelabs.com/en/projects/tradingview-order-bridge