How to Set Up TradingView Webhooks for Any Broker — Universal Guide

What a universal TradingView webhook setup actually looks like

TradingView webhooks for any broker work only when the design stays universal at the right layer. The alert transport can be universal. The execution layer cannot. A clean setup is TradingView alert -> webhook receiver -> validation and translation -> broker-specific order logic.

This distinction matters because brokers differ on authentication, symbol formats, order APIs, update streams, and rate limits. If you try to push one raw TradingView payload straight into every broker, the workflow becomes fragile immediately.

A universal bridge is valuable because it lets you standardize the alert language once and then adapt cleanly to Zerodha, Upstox, Dhan, MT4, MT5, or another supported endpoint at the execution layer.

• Keep the TradingView alert format stable and versioned.
• Translate symbols and order intent inside the bridge, not inside the chart message.
• Let each broker adapter handle its own auth and order semantics.
• Use a common logging format across all brokers so debugging stays consistent.

How to design JSON payloads that survive real brokerage logic

TradingView’s webhook help page gives the practical limits: alerts are sent as HTTP POST requests, only ports 80 and 443 are supported, the TradingView account must have two-factor authentication enabled, and the remote server has roughly three seconds before TradingView cancels the request. Those constraints are why your bridge should acknowledge quickly and defer heavier work.

Payload design is where a lot of future pain is either created or prevented. I prefer messages that include strategy name, symbol, timeframe, side, signal version, and optional risk context in clean JSON. When valid JSON is used, TradingView sets the content type to application/json, which is exactly what most modern bridges expect.

Once you standardize the payload, adding a new broker becomes a translation problem instead of a full rebuild. That is the real leverage in a universal webhook setup.

• Include only fields the bridge truly needs to make a decision.
• Give every alert versioning so future script updates do not silently break automation.
• Prefer bar-close signals when signal stability matters more than intrabar speed.
• Keep payload validation strict; rejecting a bad alert is healthier than guessing.

Why direct chart-to-order thinking causes bad automations

The chart is the wrong place to solve broker-side complexity. Your TradingView script should define signal logic and publish structured intent. It should not be the place where session validation, duplicate suppression, position checks, or auth lifecycle decisions are improvised.

This is exactly why the same chart logic can feel stable with one broker and chaotic with another. The alert is only the start of the story. The broker API decides whether the order is accepted, delayed, rejected, filled, or partially filled. If your architecture ignores that, the results become misleading very quickly.

Treating the bridge as a control layer lets you adapt to different APIs without rewriting the actual strategy logic every time you switch brokers or add a second execution venue.

• Signal logic belongs in Pine Script; execution rules belong in the bridge and broker adapter.
• Do not force symbol translation or position management into the alert text.
• Keep order-state monitoring outside the chart so broker responses remain visible.
• Use broker-specific adapters for auth, order endpoints, and status updates.

Broker-specific issues you should prepare for from day one

Some brokers use OAuth flows, some support manual or short-lived tokens, some expose WebSocket or postback order updates differently, and some apply strict rate limits on order routes. That means a universal TradingView setup should always be paired with broker-specific execution modules, even if the alert schema stays universal.

For example, Upstox documents OAuth 2.0 plus manual token generation for smaller utilities, while Dhan’s v2 docs focus on access tokens, WebSocket order updates, postbacks, and published order rate limits. Those are not edge cases; they are the operating reality of each broker.

If you design for those differences up front, you keep the webhook system reusable. If you ignore them, every new broker becomes a painful rewrite disguised as an integration.

• Map one alert schema to many broker adapters, not one generic execution function to all brokers.
• Plan token storage and refresh rules per broker.
• Capture order IDs and broker responses in a common log format.
• Decide how the system should react to rejections, timeouts, and partial fills before the first live session.

A safer launch checklist for universal webhook automation

The strongest universal setups feel simple from the outside because the complexity is contained in the right place. Signals are clean, the bridge responds fast, adapters handle broker differences, and the trader can tell what happened at every stage.

That is what I would optimize for before going live. Not maximum cleverness. Maximum clarity. If the system cannot explain where the alert came from, how it was interpreted, which broker action followed, and what status came back, then it is not ready.

• Validate JSON schema before any broker logic runs.
• Acknowledge webhooks fast and move execution into controlled processing.
• Keep separate adapters for each broker you support.
• Use order updates, postbacks, or streams to confirm actual state changes.
• Test duplicate alerts, token failures, and kill-switch behaviour deliberately.

---

Frequently asked questions