Static IP for TradingView-to-Zerodha Automation (2026 SEBI Mandate): Why Your Webhook Bot Stopped Working & How to Fix It

If your TradingView-to-Zerodha webhook bot quietly stopped placing orders around April 2026, you are not alone and nothing in your code is broken. What changed is the rulebook. A static IP for algo trading India broker whitelisting is now mandatory for every API-based order, and the brokers are rejecting any order that arrives from an IP they have not pre-registered. Your strategy still fires, your alert still hits the webhook, but the order gets silently bounced at the broker's gate.

This post explains exactly what the April 2026 SEBI framework changed, the one insight that fixes 90% of broken bots (you must whitelist the IP that actually sends the order, not your laptop), and the precise whitelisting steps for Zerodha, Dhan, Angel One, Upstox and Fyers. I build and repair these bridges for a living, so this is the same checklist I run when a client's automation goes dark.

Note: SEBI and exchange rules change, and broker portals get redesigned often. Treat the specifics below as a current-2026 snapshot and verify the exact figures and menu paths on your broker's official developer console before you act.

What actually changed in April 2026 (and why it broke DIY bots)

The trigger is SEBI's circular on safer participation of retail investors in algorithmic trading (SEBI/HO/MIRSD/MIRSD-PoD/P/CIR/2025/0000013, dated 4 February 2025). The broad framework was set in early 2025, the exchanges published the operational details later, and after a couple of deferments the whole thing became mandatory for all stockbrokers from 1 April 2026.

For a retail trader running a personal webhook bot, four changes matter most:

• Static IP whitelisting. Every API order must originate from a fixed, pre-registered public IP. Dynamic or rotating IPs are rejected. This applies to all API order placement, not just high-frequency setups.
• The 10 orders-per-second (OPS) line. Below ~10 OPS per exchange you are treated as a normal API user and do not need a separate algo registration. Cross that threshold and you need an exchange-registered strategy with an Algo-ID. Most TradingView webhook bots sit well under 10 OPS, so for them the static IP is the binding constraint, not the Algo-ID.
• Daily 2FA and no perpetual sessions. The old refresh-token flow that kept a session alive indefinitely is being wound down. You now re-authenticate (2FA) once per trading day. Bots that assumed a token would live forever break on day two.
• Order hygiene. Market orders now require market protection. An order sent with market protection of "0" (including SL-M in some setups) can be rejected. If your payload hard-codes plain market orders, expect rejections.

The static IP rule is the one that produces the most baffling symptom: nothing in your logs looks wrong, TradingView shows the alert fired, your bridge shows it received the webhook, but the broker returns an order rejection or your positions never move. That is the IP gate doing its job.

The one insight that fixes most broken bots: whitelist the IP that SENDS the order

Here is the mistake I see constantly. People whitelist their home or office IP, the one they see when they Google "what is my IP" on their laptop. But in a real TradingView-to-broker pipeline, your laptop is almost never the machine that talks to the broker.

A typical automated flow looks like this:

TradingView alert  →  webhook URL  →  your bridge / bot
(your chart)          (HTTPS POST)     (VPS, cloud function, or PC)  →  Broker API
                                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                                        THIS machine's public IP is
                                        what the broker sees and checks

The broker only ever sees the egress (outbound) IP of the machine that makes the final API call. If your bot runs on a VPS, whitelist the VPS IP. If it runs on a cloud function or container, whitelist that platform's egress IP. If it genuinely runs on your home PC 24/7, whitelist your home connection's public IP, and only if that IP is actually static.

This is also why so many cloud bots broke overnight. Cloud platforms assign dynamic outbound IPs by design. Your container can be perfectly healthy and still get rejected on every order because its public IP changed since you whitelisted it. The fix is not "trade from my laptop" but "give the order-sending machine a fixed egress IP."

To find the true egress IP, run the check from the bot's machine, not your laptop:

# SSH into the exact server/VPS that places orders, then:
curl -s https://api.ipify.org
# or
curl -s https://ifconfig.me

# That number is what you whitelist with the broker.

If you run a multi-broker setup, good news: the same static IP can be whitelisted across Zerodha, Dhan, Fyers and the rest. One properly fixed egress IP can serve all your broker accounts. If you are still wiring up the Zerodha side itself, my complete Zerodha webhook setup guide for TradingView users walks through the full bridge, and the Kite Connect + Python automation guide covers the API plumbing.

How to get a real static IP (three honest options)

There is no SEBI-issued IP. You get a static IP from your network or hosting provider, then register it with your broker. There are three realistic paths, in rough order of cost and control.

1. Cloud VPS with a reserved / Elastic IP (most robust)

Run your bridge on a small VPS in a Mumbai region (AWS ap-south-1 is closest to the exchanges) and attach a fixed IP so the egress never changes.

On AWS the clean pattern is a NAT Gateway with an Elastic IP. Your bot sits in a private subnet, all outbound traffic exits through the NAT Gateway, and the broker only ever sees that one Elastic IP:

VPC (ap-south-1, Mumbai)
 ├── Public subnet  → NAT Gateway → Elastic IP  (the IP you whitelist)
 │                                  ▲
 └── Private subnet → your bot ─────┘ (all egress exits via the Elastic IP)

Be aware of the running cost: a managed NAT Gateway is on the order of ~$33/month plus a small per-IPv4 charge, even when idle. For a single personal bot that is overkill, and a plain Mumbai VPS where the instance itself has a static public IPv4 is simpler and cheaper. Reserve the NAT Gateway design for when you are running multiple instances or want high availability across two availability zones, in which case remember to whitelist every egress IP so a failover does not silently break order placement.

2. Static-IP proxy service (cheapest, run strategy anywhere)

Several India-focused vendors now sell a dedicated static IP (or HTTP/SOCKS5 proxy credentials) specifically for broker whitelisting, with pricing commonly in the few-hundred-rupees-per-month range. You keep running your bot wherever you like and route the broker API calls through their fixed IP. This is the lowest-friction fix for a hobbyist. Two cautions: make sure the IP is dedicated to you (not shared), and confirm your broker accepts it, because some brokers flag known datacenter IP ranges.

3. Static IP from your ISP (only if your bot truly lives on-prem)

Most home broadband uses dynamic IPs. A static IPv4 usually requires a business plan and a request to your ISP, often around ₹1,500/year and up depending on the provider. This only makes sense if a dedicated machine at home or office runs the bot 24/7. Verify it is genuinely static, ISPs sometimes label a "sticky" dynamic IP as static, and a sticky IP will eventually change and break you.

Option	Rough cost	Best for	Watch out for
Cloud VPS, static/Elastic IP (Mumbai)	VPS from ~₹500–1,500/mo; AWS NAT GW adds ~$33+/mo	Always-on, reliable, low latency to exchanges	Some brokers flag datacenter IPs; whitelist every egress IP in HA setups
Static-IP proxy service	~₹250–500/mo typical	Cheapest fix, run strategy on your own machine	Must be dedicated, not shared; broker acceptance of datacenter ranges
ISP static IP (business plan)	~₹1,500/yr and up	On-prem 24/7 machine	Confirm it is truly static, not "sticky" dynamic

One operational rule to design around: most brokers let you change a whitelisted IP only about once per week. So pick an IP you can keep, and do not casually rebuild a VPS that hands you a new address, because you may then be locked out of order placement until the change window opens again.

Per-broker whitelisting steps

Every broker exposes an IP-whitelist field, but in a slightly different place. The pattern is the same: log into the developer/API portal, open your app, paste the bare IP (just 103.214.56.78, no http://, no port, no spaces), save, and test an order. If you cannot find the field, the broker's API support team will point you to it or add the IP for you.

Zerodha (Kite Connect)

1. Log in at developers.kite.trade.
2. Open your profile / app settings and find the IP Whitelist section.
3. Enter your static egress IP and save. Order requests from any other IP are rejected, regardless of order frequency.
4. Confirm your token/login flow handles the daily 2FA, since the perpetual session model is going away.

Dhan

1. Open the Dhan developer/API portal (DhanHQ).
2. In your API/app settings, add your static IP to the whitelist field.
3. Save and place a test order. Dhan has had IP whitelisting available for a while and is enforcing the mandate.

Angel One (SmartAPI)

1. Log into the SmartAPI developer portal and open your app.
2. Register your primary static IP; from 1 April 2026 SmartAPI only accepts order execution that originates from this registered IP.
3. Note Angel One's standard threshold of ~10 orders per second per exchange/segment; stay under it unless you have a registered strategy.

Upstox

1. Open the Upstox developer console and your API app.
2. Add your static IP in the app's IP configuration. Upstox was among the early-ready brokers, with IPv4/IPv6 whitelisting in place.
3. Save and verify with a test order.

Fyers

1. Log into the Fyers API dashboard and open your app.
2. Add the static IP in the app settings; the Fyers support knowledge base (support.fyers.in) has dedicated articles for the post-April-2026 app activation and for enabling a common static IP for family members.
3. If you would rather skip self-hosting entirely, Fyers Automate runs strategies inside Fyers' own infrastructure, which already satisfies the framework, no external static IP needed.

For a broader, broker-agnostic view of the alerting and routing layer, my 2026 guide to TradingView webhooks for Angel One and Zerodha ties the alert payload, the bridge and the broker call together. If you want to get the JSON right end-to-end, see the deep dive on alertcondition JSON payloads in Pine Script.

Compliance framing: are you even allowed to run this?

For most readers running a transparent, self-built strategy for their own account, the honest answer is yes, with conditions. The framework treats an individual using "white box" (transparent, self-coded) logic for personal use as a normal API user. You do not need separate SEBI Research Analyst or exchange empanelment registration for that. What you must do is route orders through a registered static IP, stay under the OPS threshold or register the strategy if you exceed it, and complete the daily authentication.

Where it gets stricter: if you sell or distribute a strategy to others, you cross into algo-provider territory, where the broker becomes the "principal" and you the "agent," and additional registration (and for opaque "black box" strategies, an RA registration) comes into play. The era of open, anonymous third-party API bridges connecting straight to the exchange is over; everything now routes through the broker's registered, traceable infrastructure with an audit chain of client to Algo-ID to static IP to API key.

If you want the bigger legal picture, I have written separately on whether algo trading is legal in India and the practical capital needed to run algo trading in India. For the wider 2026 landscape, the algo trading in India 2026 overview puts this static-IP change in context.

This is general technical information, not legal or financial advice. The framework's thresholds and definitions are set by SEBI and the exchanges and can change, so confirm current obligations for your specific setup before going live.

A practical fix-it checklist

1. Find the real egress IP by running curl https://api.ipify.org on the exact machine that calls the broker, not your laptop.
2. Make that IP static using a Mumbai VPS with a reserved IP, a dedicated static-IP proxy, or an ISP business static IP.
3. Whitelist it in each broker's developer console and save.
4. Fix the session logic so your bot re-authenticates with 2FA daily instead of relying on a perpetual token.
5. Fix order hygiene so market orders carry market protection and you do not get silent rejections.
6. Stay under ~10 OPS, or register the strategy and get an Algo-ID if you genuinely need more.
7. Place one test order in a small/safe instrument and confirm it actually fills before trusting the pipeline with size.

Get those seven right and a bot that died in April comes back to life without rewriting your strategy. The logic was never the problem, the plumbing was.

Want this fixed properly, once?

If you would rather not spend a weekend chasing egress IPs and broker portals, I do exactly this: rebuild broken TradingView-to-broker bridges so they are static-IP compliant, re-auth cleanly each day, and route orders the way the 2026 framework expects. Take a look at my TradingView automation development service, or just tell me what broke on the contact page and I will tell you honestly whether it is a 30-minute fix or a rebuild.

FAQ

Why did my TradingView-to-Zerodha bot stop working in April 2026?

Because the SEBI retail algo framework became mandatory on 1 April 2026, and it requires every API order to come from a pre-registered static IP. Your bot's outbound (egress) IP almost certainly is not whitelisted, or it is a dynamic cloud IP that keeps changing, so the broker rejects the orders even though your strategy and webhook still fire.

Which IP do I actually need to whitelist for broker API whitelisting?

The egress IP of the machine that makes the final call to the broker, usually your VPS, cloud function, or always-on server, not your laptop or your home Wi-Fi. Run curl https://api.ipify.org on that exact machine to find it, then register that number in the broker's developer console.

Do I need a static IP if my strategy only sends a few orders a day?

Yes. The static IP requirement applies to all API-based order placement regardless of frequency. The separate ~10-orders-per-second threshold only decides whether you additionally need an exchange-registered strategy and Algo-ID; it does not exempt low-frequency bots from the static IP rule.

Can I use one static IP across Zerodha, Dhan, Angel One and Fyers?

Yes. A single dedicated static egress IP can be whitelisted with multiple brokers at once. Just register the same IP in each broker's API portal. Keep in mind most brokers limit IP changes to roughly once per week, so choose an IP you can keep.

Will a free tunnel like ngrok or a VPN work for the static IP requirement?

No. Tools like ngrok and mesh VPNs solve inbound access, not a fixed outbound IP. SEBI whitelisting cares about the source IP your broker sees on outbound order calls. You need a real static egress IP, from a VPS with a reserved/Elastic IP, a dedicated static-IP proxy, or an ISP business static IP, and ideally one that is not a flagged datacenter range.

How much capital and risk discipline make sense

A common beginner mistake is thinking algo trading becomes sensible only with huge capital. That is not true. What matters first is that your strategy has stable rules, your risk per trade is defined, and your automation cannot spiral because of a repeated alert or execution mismatch.

The capital question is really a risk-control question. Can you survive a bad streak? Can you keep sizing constant while you validate the system? Can you tell whether underperformance came from the strategy, the slippage, or your execution chain? If the answer is no, adding more capital only hides the problem temporarily.

I usually suggest a staged rollout: paper logic first, then tiny live size, then gradual scaling only after the logging and post-trade review prove the workflow is behaving the way you expect.

• Do not scale a strategy you cannot explain trade by trade.
• Validate entry timing, exit timing, and broker response behavior separately.
• Use smaller size to test the system, not to chase excitement.
• Judge the stack on repeatability, not on one unusually good day.

What the retail algo framework changes for Indian traders

The reason older beginner advice is weak in 2026 is that it often ignores the current Indian environment. SEBI’s February 4, 2025 circular created the safer participation framework, and the later September 30, 2025 circular gave a glide path before making the framework applicable to all stock brokers from April 1, 2026.

You do not need to become a lawyer to act sensibly, but you do need to stop treating automation like a loose collection of Telegram hacks. A clean retail workflow now means being able to identify the strategy, control how it reaches the broker, and keep enough records to understand what happened later.

This is also why broker-specific behavior matters. The same TradingView alert can sit inside very different operating models depending on which bridge, vendor, or in-house setup you use. Production quality now means broker-aware design, not just clever chart logic.

• Know which part of your stack generates the signal and which part actually executes it.
• Avoid black-box vendor promises you cannot inspect or log.
• Keep strategy names, versions, and parameters explicit.
• Choose a workflow that can be monitored in real time and audited later.

The best route from beginner to serious operator

The beginner-to-pro path is not linear, but it is predictable. Traders who succeed usually follow this order: first define the setup, then test the chart logic, then clean the alerts, then add execution controls, and only then trust full automation with meaningful size.

Traders who fail usually reverse that order. They buy a bridge first, copy a strategy second, and only ask what the rules are after the first bad fill or duplicate trade. That sequence is emotionally exciting, but it is operationally backwards.

If you want a sustainable edge in India in 2026, think like an operator. Your broker, your logs, your alerts, and your risk rules are part of the strategy. Not separate from it. That mindset shift saves a huge amount of pain.

• Start with one market and one playbook before you add complexity.
• Use alerts to create discipline before you use them to trigger execution.
• Review every rejected order and every false trigger.
• Scale only when the boring operational parts are stable.