Most TradingView webhook tutorials show the happy path: Pine Script fires an alert, the alert hits a server, the server places an order. Works perfectly in the demo. Breaks in production in ways the demo never shows.
This post covers the full picture: how the alert-to-execution flow actually works, what you need to build at each layer, how Bybit, Binance, and Hyperliquid differ from each other, and specifically what breaks when you run this in production for the first time.
If you are building this from scratch, expect 2 to 4 weeks of engineering work for a version you can trust with real capital. If you are evaluating whether to build or buy, this post will help you scope the work accurately.
How TradingView alert execution actually works
TradingView is a charting and backtesting platform. It is not an execution platform. It cannot connect directly to an exchange, hold API keys in a secure context for live trading, or place orders on your behalf.
What it can do is send an HTTP POST request to a URL you specify when an alert condition fires. That is a webhook. Your server receives the request, validates it, and then calls the exchange API.
TradingView webhook execution flow
TradingView alert fires --> HTTP POST to your server (webhook) --> Your server validates and processes the payload --> Your server calls exchange REST API --> Exchange places the order
Every component in that chain can fail. TradingView can miss an alert during an outage. Your server can be down when the alert fires. The exchange API can return an error. The network between your server and the exchange can time out. A real production system handles all of these failure modes. The happy-path tutorial handles none of them.
Step 1: Setting up the alert in TradingView
You can trigger a webhook from either a Pine Script strategy (using strategy.entry(), strategy.exit(), or strategy.close()) or from a custom indicator alert condition using the alertcondition() function.
For strategy-based alerts, TradingView provides built-in variables you can reference in the alert message:
Example TradingView alert JSON payload
To configure the webhook in TradingView:
Create the alert
Right-click on the chart or use the Alerts panel. Select your strategy or indicator as the condition source.
Enable webhook URL
In the Notifications tab of the alert dialog, check the Webhook URL box and enter your server's endpoint. The URL must be HTTPS and publicly reachable -- localhost will not work.
Write the message body
In the Message field, write the JSON you want your server to receive. Use TradingView's placeholder variables (wrapped in double curly braces) to inject dynamic values like price, contracts, and order ID.
Set expiry
TradingView alerts expire. Set the expiry as far out as your plan allows, and build a reminder to renew it before it lapses mid-trade.
One important limitation: TradingView's {{strategy.order.contracts}} variable reflects the position size calculated by your Pine Script strategy, which uses the strategy's default_qty_type and default_qty_value settings. For production use, you will often want to ignore this value and calculate position size server-side based on actual account balance and live price.
Step 2: The webhook receiver
Your webhook receiver is an HTTP server that listens for POST requests from TradingView. It needs to do the following, in order:
Validate the request
TradingView publishes a list of IP addresses it sends webhooks from. Whitelist those IPs, or require a secret token in the payload that only your Pine Script knows. Without this, anyone who discovers your endpoint URL can send fake alerts.
Parse the JSON payload
Extract the action, symbol, quantity, and any other fields you need. Validate that all required fields are present and have the expected types. A malformed payload should be rejected immediately and logged, not forwarded to the exchange.
Check for duplicates
TradingView can fire the same alert multiple times. Use the order ID from the payload as an idempotency key. Store processed IDs in Redis or a database and reject any alert whose ID has already been processed. This is the single most important production safety mechanism in the entire stack.
Respond within 5 seconds
TradingView will consider the webhook failed if your server does not respond with a 200 status within its timeout window. Accept the request immediately and process the order asynchronously in a background task. Do not wait for exchange confirmation before responding.
Here is a minimal Python FastAPI receiver structure that shows the architecture:
Minimal FastAPI webhook receiver structure
The receiver itself should be stateless where possible. State (current position, daily P&L, circuit breaker status) belongs in a persistent store like Redis or PostgreSQL, not in application memory. A server restart must not cause you to lose track of your position.
Step 3: Exchange connectivity
Each exchange has its own API structure. The core differences that affect your implementation:
Bybit (USDT perpetuals):
Bybit's v5 API uses a category parameter to distinguish between spot, linear (USDT perps), and inverse contracts. For USDT-margined perpetuals, every order request needs category: "linear". Order side is "Buy" or "Sell" (capitalized). Bybit supports market, limit, conditional, and TP/SL orders in a single request via takeProfit and stopLoss fields.
Binance (USDM futures):
Binance futures use a separate base URL from spot (https://fapi.binance.com). The API key and secret are the same, but the endpoints are completely different. Order side is "BUY" or "SELL" (all caps). Binance uses positionSide for hedge mode (both long and short positions simultaneously) versus one-way mode. If your account is in hedge mode, every order needs an explicit positionSide field or it will be rejected.
Hyperliquid:
Hyperliquid has its own Python SDK (hyperliquid-python-sdk) and a significantly different order structure from CEX APIs. Orders are signed with a private key using EIP-712 signatures rather than HMAC-SHA256. The order format uses coin instead of symbol, and quantities are specified as decimal values with specific precision requirements per asset. If you are coming from Binance or Bybit, expect to spend meaningful time reading the Hyperliquid documentation before your first successful order.
All three exchanges enforce rate limits. Bybit and Binance allow burst requests but will return HTTP 429 errors if you exceed per-second or per-minute limits. Your receiver should implement exponential backoff and alert you when rate limit errors occur rather than silently dropping orders.
Step 4: The risk layer you must build
Your webhook receiver has zero built-in risk controls. TradingView has zero built-in risk controls on the execution side. The exchange will accept whatever order you send, as long as it is technically valid and you have the balance.
This means a Pine Script bug that fires an alert on every bar -- or an adversary who finds your webhook URL -- can place hundreds of orders in seconds. You must build the risk layer yourself.
Minimum required controls:
Maximum position size
Hard cap on the dollar value of any single position. Even if the Pine Script sends a quantity of 10 BTC, your server should cap at your configured maximum before sending the order.
Daily loss limit
Track realized P&L for the day. If losses exceed your daily limit, reject all new entry orders until the next session. Exit-only orders should still be allowed.
Maximum open positions
Set a limit on how many positions can be open simultaneously. This prevents runaway logic from pyramiding into a single position or opening dozens of positions at once.
Alert frequency circuit breaker
If your receiver gets more than N alerts per minute from the same strategy, something has gone wrong. Stop accepting orders from that strategy and send yourself a notification immediately.
Step 5: State management
TradingView does not know whether you are currently long, short, or flat. Your receiver has to track this.
The common failure mode: your Pine Script fires a "buy" signal when you are already in a long position. What should your server do? Three reasonable answers, each appropriate in different circumstances:
- Ignore the signal (already long, position is open)
- Add to the position (intentional pyramiding)
- Close the existing long and reopen (re-entry logic)
None of these is the default. You have to implement the one that matches your strategy's intent.
Position state must persist across server restarts. If your server crashes while you are in a position and you restart it, it needs to know your current position before accepting any new signals. At startup, query the exchange for your current positions and reconcile against your internal state. Treat any discrepancy as an alert condition, not a state to silently override.
For multi-strategy setups where multiple Pine Script strategies send signals to the same receiver, you need per-strategy position tracking. Strategy A being flat should not cause the server to reject a signal from Strategy B, which has its own independent position.
What breaks in production
Experience rather than theory:
Duplicate alerts
TradingView sometimes fires an alert two or three times in rapid succession for the same condition. Without idempotency keys, this places duplicate orders. This is not hypothetical -- it happens regularly.
Server downtime during market moves
If your VPS reboots during a sharp move, you miss the alert. TradingView does not retry webhooks for missed alerts. You are now in a state where your strategy has a signal but no position was placed. The next alert may try to exit a position that was never entered.
Bar-close timing vs. fill timing
TradingView strategy backtests fill at the bar close. The webhook fires at the bar close, but then adds 100 to 500ms of latency before the order reaches the exchange. In high-volatility moments, the fill price can be significantly different from what the backtest assumed. Always measure your live slippage against the backtest assumption.
Exchange rate limits during alert bursts
If multiple alerts fire simultaneously (multiple strategies, multiple timeframes), your requests can hit exchange rate limits. Orders are silently dropped unless you handle 429 responses explicitly with retry logic.
Alert expiry
TradingView alerts expire. A strategy that has been running for months will silently stop sending webhooks when the alert expires. Your monitoring needs to detect when a strategy that should be generating signals goes quiet.
When to use a pre-built connector vs. building your own
Pre-built connectors (WunderTrading, Alertatron, 3Commas webhook mode) are reasonable when your setup is simple: one strategy, one exchange, low frequency, no custom position sizing logic, and you are comfortable with the provider having access to your exchange API keys.
Build your own when:
- You need server-side position sizing based on live account balance
- You are aggregating risk across multiple strategies
- You need custom logic for position state (pyramiding rules, re-entry conditions)
- You want exchange API keys to never leave your infrastructure
- You need audit logging and monitoring that integrates with your own systems
The tradeoff is straightforward: a pre-built connector costs $30 to $100 per month and takes an hour to set up. A custom receiver costs 2 to 4 weeks of engineering work and ongoing maintenance. For simple setups, the connector wins. For anything requiring real risk control or production reliability, the custom build is the correct path.
Summary checklist
- TradingView cannot place orders directly -- it sends HTTP POST webhooks to your server
- Your webhook receiver needs HTTPS, IP validation or token auth, and must respond within 5 seconds
- Implement idempotency keys using the alert ID to prevent duplicate orders
- Handle Bybit, Binance, and Hyperliquid API differences explicitly -- they are not interchangeable
- Build a risk layer before going live: position size limits, daily loss limits, alert frequency circuit breakers
- Track position state server-side and persist it across restarts
- Query exchange positions at startup and reconcile against internal state
- Monitor for duplicate alerts, missed alerts, bar-close fill gaps, and alert expiry
- Compare live fill prices against backtest assumed prices to measure real-world slippage
- For simple setups, use a pre-built connector; for production reliability, build your own
Want this built properly?
Building a webhook receiver that handles production failures, duplicate alerts, position state, and risk controls is 2-4 weeks of engineering work. We build this infrastructure for clients -- see how the D&T Systems TradingView automation service works.
Frequently asked questions
Can TradingView execute trades directly on exchanges?
No. TradingView cannot place orders on exchanges itself. It can send webhook alerts to an external server when a Pine Script condition is met. That server -- your webhook receiver -- is responsible for receiving the alert, validating it, and submitting the order to the exchange via the exchange's REST or WebSocket API.
What is a webhook in TradingView?
A TradingView webhook is an HTTP POST request that TradingView sends to a URL you specify when an alert fires. The request body is JSON that you define in the alert message field. Your server receives this request and can use it to trigger any action, including placing a trade on an exchange.
How do I set up a TradingView webhook?
In TradingView, create an alert on your strategy or indicator. In the alert settings, enable webhook and enter the URL of your server. In the alert message field, write the JSON payload your server will receive. Your server must be publicly accessible (not localhost), use HTTPS, and respond with a 200 status within TradingView's timeout window.
What are the risks of TradingView webhook automation?
Main risks include: duplicate order execution (TradingView may fire the same alert multiple times), missed alerts during TradingView outages, no built-in position tracking so your server must manage state, no exchange connectivity fallback if your server goes down, and no risk controls unless you build them explicitly. A production system needs idempotency keys, state management, and circuit breakers.
Does TradingView strategy backtesting account for webhook latency?
No. The TradingView strategy tester assumes instantaneous fills at the bar close. A real webhook flow adds at least 100-500ms of latency between the alert firing and the order reaching the exchange. In fast markets this can mean significantly different fill prices. Always compare live fill prices against the strategy's assumed prices to measure the gap.
Want this built properly?
Building a webhook receiver that handles production failures, duplicate alerts, position state, and risk controls is 2-4 weeks of engineering work. We build this infrastructure for clients -- see how the D&T Systems TradingView automation service works.