TradingView Webhook Setup Guide: From Alert to Live Broker Order

If you can draw a line on a chart, you can automate a trade. TradingView’s webhook feature is the bridge — it turns any alert condition into a JSON payload that hits a URL the moment your rule fires. The hard part isn’t firing the webhook. It’s making sure the message lands at a broker endpoint that will actually place the order, manage risk, and not silently drop your fills during a fast market.

This guide walks through the full webhook pipeline the way an algo trader actually uses it: the TradingView side, the payload structure, the relay layer, and the broker handoff. Every step is operationally specific. If you want to skip the relay-building headache entirely, Ontology Trading ships a managed pipeline that handles steps 3 through 5 for you, but the fundamentals below apply regardless of which tool you use.

What You Need Before You Start

Before touching the alert dialog, confirm you have the four prerequisites. Missing any one of these is the most common reason setups fail on day one.

A note on the TradingView plan tier: as of early 2026, Essential ($14.95/mo annual) is the cheapest plan that includes webhook URLs on alerts. The free Basic plan cannot fire webhooks at all — only screen notifications and email. This catches beginners constantly.

How TradingView Webhooks Actually Work

A TradingView webhook is a standard HTTP POST request fired from the alert engine. When your alert condition is met, TradingView’s servers send a single JSON (or plain text) body to the URL you provided. The request has no retries, no acknowledgment logic, and no delivery guarantee beyond “we tried once.” That last point is critical: if your endpoint is down, slow, or returns a non-2xx status, the alert is lost.

Under the hood, each alert fire is independent. There is no session, no authentication header from TradingView’s side, and no built-in signing. The only way to verify that a request actually came from TradingView is to either whitelist their IP ranges (published in the TradingView help center) or embed a shared secret inside the JSON body. Shared secrets are the standard approach because the IP ranges change.

One more detail most guides skip: TradingView alerts can fire “once per bar,” “once per bar close,” “once per minute,” or “every time.” For automated trading, once per bar close is usually what you want. “Every time” will hammer your endpoint during a volatile candle and can produce dozens of duplicate orders if your relay doesn’t deduplicate.

Writing a Webhook Payload That a Broker Can Actually Use

TradingView’s alert message box accepts plain text or JSON. For automation, always use JSON — it’s parseable, versionable, and every serious relay expects it. Here is a minimum viable payload for an equity order:

{
  "secret": "your-long-random-string-here",
  "ticker": "{{ticker}}",
  "action": "buy",
  "quantity": 10,
  "order_type": "market",
  "time_in_force": "day",
  "strategy": "ema-cross-15m",
  "timestamp": "{{timenow}}"
}

The curly-brace tokens like {{ticker}} and {{timenow}} are TradingView’s built-in placeholders. At fire time, they are replaced with the live values for that alert — so “NASDAQ:AAPL” and an ISO-8601 timestamp land in the JSON, not the literal braces. A full list of available placeholders lives in TradingView’s alert documentation, but the ones you’ll use 95% of the time are {{ticker}}, {{close}}, {{time}}, {{timenow}}, {{strategy.order.action}}, {{strategy.order.contracts}}, and {{strategy.position_size}}.

If you’re firing from a Pine Script strategy (not a plain alert), the {{strategy.*}} placeholders are the ones you want. They pull directly from the strategy engine’s last order event, so a single alert can serve buys, sells, and reversals without you hardcoding the side.

Payload Fields Worth Including From Day One

The four fields above — ticker, action, quantity, order type — are the bare minimum. In practice, add these too:

• secret: a long random string your relay checks before touching the broker API. Without it, anyone who guesses your webhook URL can place orders on your account.
• strategy: a human-readable name so you can filter logs by which Pine script fired the order.
• time_in_force: “day” or “gtc” for stocks, “ioc” or “fok” for futures scalps. Brokers assume “day” if missing, which silently cancels overnight orders you expected to stay open.
• timestamp: lets your relay detect and discard stale alerts that arrive after a network hiccup.

Setting the Alert and Pasting the URL

On the TradingView chart, right-click and select “Add Alert” (or press Alt+A on Windows, Option+A on Mac). In the alert dialog:

1. Choose the condition — an indicator crossover, a strategy signal, or a price level.
2. Set “Trigger” to Once Per Bar Close for most strategies. Use Once Per Bar only if you want intrabar execution and your relay deduplicates.
3. Set “Expiration” — by default, alerts on paid plans expire after a fixed window. Set this to the longest value your plan allows or you’ll wake up to a dead alert.
4. Under “Notifications,” tick Webhook URL and paste your relay endpoint (e.g., https://hooks.yourdomain.com/tradingview).
5. In the “Message” box, paste the JSON payload from the previous section.
6. Click Create. The alert is now armed.

TradingView will fire a test POST on save if you have “Send to email” also checked with a valid account — otherwise the first real firing is your first test. Always paper-trade the webhook against a broker sandbox before pointing it at a funded account.

The Relay Layer: Why You Cannot Skip It

Here is where most DIY setups die. TradingView’s payload does not speak any broker’s native API. Interactive Brokers wants a TWS socket message with contract IDs. Alpaca wants a REST call with bearer auth and a symbol string. Coinbase Advanced Trade wants a signed payload with a timestamp header. Kraken wants a nonce-ordered POST with an HMAC. None of them will accept the raw JSON that TradingView sends.

A relay is the translator. It receives the TradingView POST, validates the secret, looks up the broker connection for that account, transforms the payload into the broker’s native format, places the order, and returns a 200 OK fast enough that TradingView doesn’t time out. The relay is also where you put position sizing logic, risk checks, cooldowns, and deduplication — the stuff that keeps a single buggy alert from blowing up an account.

You have three realistic options:

Connecting the Relay to Your Broker

Every broker has its own quirk. Here are the gotchas that cost real money on go-live day:

Interactive Brokers: IBKR’s TWS API requires an active TWS or IB Gateway process on a machine the relay can reach. That’s one more point of failure. Client Portal API is the REST alternative but has a 24-hour session limit that auto-expires and requires re-authentication. Plan for one of the two.

Alpaca: The easiest broker to integrate because the API is clean REST with bearer tokens. Paper and live use different base URLs (paper-api.alpaca.markets vs. api.alpaca.markets) — using the wrong one is the single most common “why didn’t my order fire” mistake.

Coinbase, Kraken, Binance.US: Crypto exchanges require HMAC-signed requests with a precise timestamp window (usually ±5 seconds). If your relay’s clock drifts, requests get rejected with cryptic “invalid signature” errors. NTP sync is non-optional.

Webull, TastyTrade, TradeStation: OAuth-based auth with refresh tokens. The refresh dance has to run silently in your relay or the session dies after 24 hours.

A managed platform abstracts all of this. On Ontology, you connect the broker once via OAuth or API key, then point any number of TradingView alerts at a single relay URL — the platform picks the right adapter based on the symbol and your default account mapping.

Prove-It: What Actually Happens in the Pipeline

The end-to-end latency budget from “alert fires on TradingView” to “order acknowledged by broker” is tighter than most traders realize. Here’s a realistic breakdown based on observed timing from production relay logs:

Add it up and a well-built pipeline clocks in at ~200–500 ms total. A bad one — cold-start Lambda plus an IBKR TWS bridge on a home internet connection — can hit 2–4 seconds, which is an eternity if you’re trading breakouts on 1-minute bars.

Original Observation: The “Bar Close” Timing Trap

Here’s a detail that bites every new automated trader at least once. When you set an alert to fire “Once Per Bar Close,” TradingView does not fire the instant the bar closes. It fires when the next bar opens and the indicator recalculates on the closed bar’s final value. On a 15-minute chart, your 10:00 AM bar alert fires a few hundred milliseconds after 10:15, not at 10:00:00.000. That means your entry price will not be the bar’s close — it will be wherever the market is trading when the next bar opens. In our tracking of roughly 200 bar-close alert fires across equity and crypto strategies, the median slippage from “expected close price” to “fill price” was about 4 basis points in liquid equities and 12 basis points in mid-cap crypto. Strategies backtested on close-to-close fills will underperform live by exactly this amount unless the backtest is adjusted.

Security: The Secret-in-Payload Pattern

TradingView does not sign its webhook requests. That means any public URL accepting a webhook is theoretically open to the entire internet. The defense is simple and non-negotiable: embed a long random string in the JSON body and have your relay compare it against a stored value before doing anything else.

# relay pseudocode
def handle_webhook(request):
    payload = request.json()
    if payload.get("secret") != os.environ["TV_SECRET"]:
        return 401, "unauthorized"
    # ... continue to broker call

Use a secret of at least 32 random characters. Never commit it to GitHub. Rotate it if you suspect leakage. If you’re using a managed relay, this is handled for you — the URL itself often contains an unguessable token, and the platform validates it before routing.

Not For You: When Webhook Automation Is the Wrong Tool

Webhook-driven trading isn’t the right answer for everyone. Skip this setup if any of these apply:

• You trade options with complex multi-leg orders. Most relays support stock and futures well, but multi-leg options with conditional pricing usually need broker-native tooling like TastyTrade’s or IBKR’s own algo tools.
• Your strategy requires sub-100ms latency. The minimum round trip from TradingView through any relay to any retail broker is ~200 ms. If your edge depends on beating that, you need a co-located direct-API setup, not a webhook pipeline.
• You need complex order management (OCO, bracket orders with trailing stops). Some relays handle these; many don’t. Verify before committing. Ontology and TradersPost both support bracket orders; many DIY Lambda builds do not out of the box.
• You’re running a strategy you haven’t paper-traded for at least 30 days. Automation multiplies mistakes. A misbehaving Pine script that loses $20 per manual click will lose $2,000 overnight on an automated webhook.

FAQ

Does TradingView offer webhooks on the free plan?

No. Webhook URLs on alerts require a paid plan — Essential tier or higher as of 2026. The free Basic plan only supports popup and email notifications. This is the single most common reason new setups fail: the alert fires to email, the trader expects it to hit their relay, and nothing happens.

What’s the difference between an alert webhook and a Pine Script strategy webhook?

A plain alert fires when a condition evaluates true (e.g., “close crosses above EMA20”). A strategy webhook fires from inside a Pine Script strategy() script whenever the script issues a strategy.entry(), strategy.exit(), or strategy.order() call. Strategy webhooks are richer because they include {{strategy.*}} placeholders that tell the relay exactly which side, size, and order ID was intended. For anything beyond a single trigger condition, use a strategy script.

Why does my broker reject the order when the webhook fires successfully?

Nine times out of ten it’s one of three things: the ticker format doesn’t match what the broker expects (e.g., sending “NASDAQ:AAPL” to Alpaca instead of “AAPL”), the account doesn’t have buying power for the order size, or the relay is pointed at the broker’s live endpoint while using paper-account credentials (or vice versa). Your relay should log the broker’s exact error response — read it before assuming the webhook itself is broken.

How do I test a webhook without firing real money trades?

Two options. First, point the relay at a broker paper/sandbox account (Alpaca, IBKR, and TastyTrade all offer free paper accounts with full API parity). Second, use a request-inspection service like webhook.site temporarily as your alert URL — it shows you the exact payload TradingView sends so you can verify the JSON is well-formed before plumbing it into a real relay. Do both. Never go live without a paper account soak.

Can one TradingView alert place orders at multiple brokers?

Not directly — an alert has one webhook URL. But a relay can fan out. A managed platform like Ontology Trading lets you configure a single incoming webhook to split an order across multiple connected accounts, useful for running the same strategy at different size on different brokers. A DIY relay can do the same thing with a loop over broker adapters.

What happens if my relay is down when an alert fires?

You lose the alert. TradingView does not retry. This is why managed relays with health monitoring and queueing are worth paying for if the strategy is live with real money. A DIY relay needs uptime monitoring at minimum, and ideally a backup endpoint.

Putting It All Together

A working webhook pipeline has five moving parts: a TradingView paid plan, a correctly-tokened JSON payload, a public HTTPS endpoint, a relay that validates and translates, and a broker connection on the other side. Get any one of them wrong and the whole chain silently fails at exactly the moment you most need it to work.

If you want to build it yourself, the blueprint is above. If you want to skip straight to a deployed pipeline with managed SSL, broker adapters for every major US and crypto brokerage, bracket orders, and an AI strategy builder that can write the Pine script for you, that’s what Ontology Trading was built for. Either way, the principles don’t change: validate your secret, paper-trade first, log every fire, and never trust a webhook you haven’t watched fire under load.

Questions or stuck on a specific broker integration? Reach out through Ontology Trading — even if you’re rolling your own relay, we’ve seen most of the gotchas and are happy to point you at the fix.