Do I need TradingView Premium for webhooks?

Webhook alerts require a paid TradingView plan (Pro and above currently include them). The receiver side is fully in your control regardless of plan.

Latency from alert to order?

Typically 200–600 ms end-to-end: TradingView dispatch, your receiver processing, and the broker API call over a Mumbai static IP. Fine for swing/momentum systems; not for HFT.

TradingView Webhook to Broker Order: Automation with a Static IP

Turn TradingView alerts into real broker orders in India — webhook receiver setup, static IP whitelisting, and a secure Python bridge to Zerodha or Fyers.

How the pipeline works

TradingView fires a webhook (HTTP POST with your alert JSON) whenever your strategy or indicator condition triggers. A small receiver service you run catches that POST, validates it, and places the corresponding order through your broker's API. The broker sees the order coming from your server — which is why the origin IP matters.

The two IPs in this system

Inbound: TradingView's servers POST to your receiver's public URL. TradingView publishes its own source IPs, which you can allow at your firewall.
Outbound: your receiver calls the broker API. THIS traffic must exit from the static IP you whitelisted with the broker.

Receiver skeleton (Flask)

Security checklist

Put a shared secret inside the TradingView alert message body and verify it server-side.
Serve the webhook over HTTPS (nginx + Let's Encrypt in front of Flask).
Rate-limit the endpoint and reject malformed payloads before touching broker code.
Never place raw alert values into orders without bounds checks (max quantity, allowed symbols list).

Why the static IP is non-negotiable here

Webhook receivers typically run on small cloud VMs whose default IPs are recycled and non-Indian. Brokers may geo-flag those ranges, and any VM rebuild changes the address. Routing the outbound broker calls through your dedicated Indian static IP means the VM is disposable but your broker identity is permanent.