"IP Not Whitelisted": Why Your Broker Keeps Rejecting API Orders — and How to Fix It

Since IP whitelisting became enforced across Indian broker APIs, one complaint dominates every developer forum: "I've whitelisted my IP and my orders are still getting rejected." Scroll the Kite Connect forum, the SmartAPI forum or the Upstox community and you'll find the same thread posted over and over, usually with no conclusive answer.

Here's the thing almost every one of those threads eventually discovers: the IP was never really the problem. The whitelist entry is usually correct. What's wrong is that the request arriving at your broker is coming from a different address than the one you think you're sending from — and there are seven distinct ways that happens.

Start Here: Find the IP Your Broker Actually Sees

Every fix below depends on knowing one number: the public IP address that your order request is actually arriving from. Not the IP on your dashboard. Not the IP your ISP told you. The one the broker sees.

Run this from the machine (or server, or container) that places your orders — not from your laptop, unless your laptop is genuinely what talks to the broker:

# What IPv4 address do I appear as?
curl -4 https://api.ipify.org

# And critically — am I *also* reachable over IPv6?
curl -6 https://api64.ipify.org

That second command is the one people skip, and it is the single most common root cause on this page. Read Cause 2 before you dismiss it.

Now compare:

• The two numbers match your whitelist entry → your problem is a token, a cooldown, or an account conflict. Jump to Cause 4.
• They don't match → your problem is the IP itself. Causes 1, 2, 3 or 7.

What Your Exact Error Code Means

Brokers all reject the same thing, but they name it differently. Find yours:

Cause 1: Your Home IP Changed (The Silent One)

This is the classic. It worked yesterday. You changed nothing. Today every order 403s.

Almost all Indian home broadband is dynamic: your public IP is leased to you, and it rotates on a router restart, a power cut, a line flap, or whenever your ISP feels like refreshing the lease. The moment it rotates, your whitelist entry points at an address that is no longer you — and quite possibly now belongs to a stranger down the road.

Nothing warns you. There's no email, no dashboard banner. Your algo simply stops being able to trade, usually at the worst possible moment.

The fix: stop whitelisting an address you don't control. You need an IP that is genuinely static and genuinely yours — whether that's a paid static-IP add-on from your ISP (if they offer one and you're not behind CGNAT), a cloud server, or a dedicated static IP service.

Cause 2: The IPv6 Trap — the One That Catches Everybody

This is the cause that produces the most maddening threads, because everything looks correct. Your IPv4 address is right. It's typed correctly. It's saved. And orders still fail.

Here's what's happening. Your machine has both an IPv4 and an IPv6 address. When it connects to your broker, modern networking stacks generally prefer IPv6. So your request goes out over IPv6 — from an address that is nowhere in your whitelist. The broker sees an unrecognised address and rejects you. Your perfectly correct IPv4 entry is never even consulted.

This has been reported directly by Upstox users hitting UDAPI1154 on a server whose IPv4 was correctly whitelisted — the traffic was simply leaving over IPv6.

The fix — force your client to use IPv4:

• Python (requests / urllib3): force the connection family to AF_INET, or run on a host with IPv6 disabled.
• Node.js: set family: 4 in your request agent options.
• curl: pass -4.
• Cloud VMs: the cleanest fix is usually to disable IPv6 on the network interface entirely, so there is no ambiguity about which stack your orders leave on.

Then re-run curl -4 https://api.ipify.org and confirm the address matches your whitelist exactly.

Cause 3: The Order Doesn't Leave From Where You Think

A rule that sounds obvious and is violated constantly: you must whitelist the IP of the machine that makes the final API call to the broker. Not the machine you're sitting at.

The tell-tale symptom: it works when you run the script on your laptop, and fails once you deploy it. That is this cause, essentially every time.

Cause 4: Your Token Was Issued Before the Whitelist Change

Suppose your IP is correct and verified. Orders still fail. This is why.

Some brokers bind your session or access token to the IP it was created from. If you generated your token, then updated the whitelist, that token is still carrying the old association. The whitelist is right; the token is stale. The broker rejects on the token, not the entry.

This is well documented across brokers, and each words it differently:

• Dhan says it outright in its own support notes: if you added the IP after generating your access token, you must regenerate the token — otherwise you keep getting DH-905.
• Upstox goes further: changing your registered static IP invalidates your existing access tokens. You have to redo the OAuth flow. If you change the IP and keep using the old token, you have simply traded one 403 for another.
• Kotak Neo has a dedicated error for it — 1037 — and requires the session itself to have been created from the whitelisted IP.
• Zerodha behaves similarly: the change lands on your next login or token regeneration, not instantly.

Cause 5: "IP Already Linked to Another Account"

A distinct and confusing failure: the broker won't even accept the IP you're trying to register.

The reason is regulatory rather than technical. SEBI's requirement is that an API order be uniquely attributable to a specific person. Brokers implement this literally: one static IP maps to one client. If the address you're registering is already on someone else's account, it's refused.

This bites in predictable places:

• Shared office or co-working internet — a colleague already claimed the IP.
• A shared VPS or shared hosting IP — you don't have it to yourself.
• Cheap "dedicated" proxies — that turn out to be shared with other buyers. This is a real risk at the very low end of the market, and it is precisely the corner you cannot afford to cut here.
• Two family members trading from one home connection — genuinely common.

Outside a family group, the fix is an IP that belongs to you alone. "Dedicated" has to actually mean dedicated — and it's worth being blunt that this is where the cheapest end of the market quietly fails you.

Cause 6: The 7-Day Change Cooldown

This one converts an inconvenience into an outage, and almost nobody sees it coming.

Brokers rate-limit how often you may change a whitelisted IP. Zerodha (once per calendar week), Dhan (locked for 7 days after you set it), Kotak Neo and ICICI Direct all impose roughly a one-week cooldown.

Follow the logic through, because it's brutal:

1. Your dynamic home IP rotates overnight. Your algo stops trading.
2. You update the whitelist to the new IP. Fine — you've now spent your one change.
3. Two days later, your ISP rotates it again.
4. You go to update it… and the broker won't let you. You are locked out of API trading for five more days, and there is no appeal.

Cause 7: A VPN or Shared Proxy Is Rotating Your Exit IP

Reaching for a consumer VPN is a natural instinct and a poor solution. Standard VPN plans put you behind a shared exit IP that changes between sessions and is used by many other customers simultaneously. Every problem on this page at once: the address moves (Cause 1), it isn't yours (Cause 5), and correcting it burns your cooldown (Cause 6).

"So I'll buy the dedicated-IP add-on," you think. Reasonable — and this is where India turns out to be a dead end.

In June 2022, CERT-In directed VPN providers to retain customer identity data for five years. Rather than comply, NordVPN, ExpressVPN, Surfshark and Proton pulled their physical servers out of India. Their "India" locations today are generally virtual — physically hosted abroad, commonly in Singapore. The consequence:

• NordVPN and Surfshark don't offer an Indian dedicated IP at all. India isn't on either provider's dedicated-IP location list. You can buy a dedicated IP — it just won't be Indian.
• PureVPN does market an India dedicated server (Mumbai / Bangalore / Delhi NCR) — but its own documentation says it is shared by up to five users. That collides head-on with Dhan's "each individual needs a unique static IP" and Zerodha's "each IP can only be linked to one account." It is precisely the thing the rule forbids, sold under the word "dedicated."

The fix: a single dedicated IP that doesn't rotate and isn't shared. Whatever you buy, the question to ask the vendor is exactly one sentence long: "Is this IP used by anyone but me?" If the answer is anything other than a flat no, it will not solve this problem.

The Datacenter-IP Myth (An Honest Answer)

You will read, in a lot of places, that Indian brokers block or flag AWS, Google Cloud and other datacenter IP ranges, and that you therefore must buy a residential IP.

We went looking for evidence of that in the brokers' own documentation. We couldn't find any. What we found was the opposite:

• Zerodha's own support documentation tells you to acquire a static IP "from an ISP, cloud provider (AWS, GCP, etc.), or a VPN/VPC service."
• Kotak Neo's static-IP documentation explicitly names AWS, DigitalOcean, Azure and Google Cloud as ways to get one.
• Fyers tells users to contact "your internet service provider or cloud service provider."
• Angel One's SmartAPI guidance says you can get a static IP "from your cloud provider (if you are running your code from the cloud)."

Four brokers, naming cloud providers approvingly, in their own words. No broker documentation we reviewed bans cloud or datacenter ranges. So we won't tell you it does — even though we sell a static IP and it would be a convenient thing to say.

If you already run a cloud VM with a reserved IP and it works, keep it. It is a legitimate, broker-sanctioned way to comply. We'd rather you trust the other eleven sections of this page.

What the brokers do insist on is different, and it's worth stating plainly, because it's the thing that actually governs whether your setup is legal and working: the IP must be fixed, and it must be yours alone. SEBI's requirement is traceability — an order must be attributable to one identifiable person. Where the address is hosted is your business. Whether it moves, and whether you share it, is theirs.

Making This Never Happen Again

Every cause on this page reduces to one of two questions. Is the address stable? And is it exclusively yours? Any option that answers "yes" to both makes this entire category of problem disappear:

There's no single right answer here. If you're comfortable running a server, the cloud route is legitimate and brokers endorse it. If you're not — and most traders would rather spend their attention on strategy than on patching a VM — a dedicated IP that simply arrives, works, and doesn't move is the shorter path.

Frequently Asked Questions