Why your API says "IP not whitelisted" and how to fix it for good

The key is right, the code hasn't changed, and every call still fails with "IP not whitelisted". The API isn't looking at your key. It's looking at where the request came from.

Last updated 29 October 2026 · 5 min read

It worked yesterday. Today the same call comes back with a 401 or 403 and a message about your IP. You regenerate the key, check the headers, restart the script. Nothing.

An "IP not whitelisted" error means the server compared the address your request arrived from with the list of addresses allowed for your account, and it didn't match. Fixing it takes two parts: put the right address on the list today, and make sure the address you send from stops changing. If you'd rather skip the second part, a static IP for API whitelisting gives your calls one fixed address. The rest of this guide shows how to sort it out either way.

What "IP not whitelisted" actually checks

Every request reaches the API from a public IP address. That's the address of whatever sits between you and the internet: your home router, your office firewall, your cloud provider's gateway. It is not the 192.168.x.x address you see in your laptop's network settings. That one never leaves your local network.

The platform keeps a short list of public addresses it trusts for your key. If the request comes from anywhere else, it's rejected before your key is even considered. The wording varies. Delta Exchange returns ip_not_whitelisted_for_api_key. WazirX uses error 2128, "This IP has not been whitelisted for the API key". Banks and payout providers often just say "unauthorised". The cause is the same.

Step 1: find the IP the API actually sees

Run this on the same machine that makes the API calls. If your code runs on a server, run it on the server, not your laptop.

curl https://ifconfig.co
curl -4 https://ifconfig.co   # your IPv4 address
curl -6 https://ifconfig.co   # your IPv6 address, if you have one

No terminal handy? Open our what's my IP tool in a browser on that machine. Now compare the result with what's on the allowlist. Nine times out of ten they're different, and the rest of this guide is about why.

Why your IP changed

Your home or office internet is dynamic

Most broadband in India gives you a dynamic address. It can change when the router restarts, which happens every time there's a power cut, or when the ISP simply reassigns it. Office lines are often no different unless the company pays for a business plan with a static IP.

You're behind CGNAT

Many Indian connections don't get a public IP of their own at all. The ISP puts lots of customers behind one shared public address, called carrier-grade NAT. Check the WAN address on your router's status page. If it's between 100.64.0.0 and 100.127.255.255, that's the range RFC 6598 sets aside for CGNAT, and the public address the API sees is shared with strangers and can move under you.

The request went out over IPv6 instead of IPv4

If your connection has both IPv4 and IPv6, your system may pick either one for a given call. Say you whitelisted your IPv4 address, but the API's server also has an IPv6 address. Some calls go out over IPv6, from an address that isn't on the list, and fail at random. The curl -4 and curl -6 checks above show you both. Either whitelist both or force your client to use one.

Your cloud server got a new outbound address

A cloud server doesn't always keep its outbound IP. A redeploy, a replaced instance or autoscaling can bring a new one unless you've attached a fixed address. Serverless functions and many hosting platforms go out through shared pools of addresses that change and that other customers use too.

You're on a VPN or a different network

Testing from home, the office and a phone hotspot in one week means three different addresses. A VPN adds a fourth. Whichever one you whitelisted, the others fail.

Fixes that only work for a while

Adding each new IP as it appears. It gets you going today. It also leaves a growing list of old addresses on your account, some of which now belong to other people on the same ISP. Many platforms cap how many IPs you can add, and some, like government APIs, take days to approve a change.

Turning the allowlist off. Where that's allowed, it works until a key leaks. Then anyone, anywhere can use it. For payouts or trading, that's a bad trade.

Waiting for the IP to come back. It sometimes does. Not on a schedule you can plan around.

The fix that lasts: send from an address you control

What you need is one public address that is yours, doesn't change, and that your API calls always leave from. There are three common ways to get it.

A static IP from your ISP

Business broadband plans often include one. ACT, for example, lists a free static IP on business plans that start at ₹5,999 a month plus GST, and JioBusiness plans come with a public static IP. Fine for an office. It doesn't help when you work from home or move the code to a server.

A fixed IP from your cloud provider

Most cloud providers let you attach a fixed public address to a server, or send a private network out through a gateway with a fixed address. It works well for code that lives on that one setup, but costs extra and ties the address to that provider.

A dedicated static IP you route through

This is what we built TrueIP for. You get a dedicated IPv4 or IPv6 address in Mumbai, with its own proxy login. Point the HTTP client that talks to the API at it, and those calls leave from your fixed address, whether the code runs on your laptop, a VPS or a serverless function. Everything else on the machine keeps its normal route.

import requests

api = requests.Session()
api.proxies = {"https": "http://USER:PASS@HOST:PORT"}
r = api.get("https://api.example.com/v1/orders")

HTTPS stays encrypted end to end, so we only see a destination host, not your keys or data.

Which address type to whitelist

Check what the allowlist accepts before you pick. AWS security groups, Cloudflare, GitHub and Microsoft Entra take IPv6 ranges. Stripe's API key restrictions take IPv4 only. Banks, payout providers and government APIs mostly don't mention IPv6, so IPv4 is the safer pick there. Honestly, if you're unsure, go with IPv4.

Quick checklist

• Run curl -4 https://ifconfig.co and curl -6 https://ifconfig.co on the machine making the calls.
• Compare both with the allowlist. Add the right one, or force your client to one IP version.
• Check your router's WAN address for the 100.64 to 100.127 CGNAT range.
• Remove old addresses you no longer use from the allowlist.
• Move the calls to an address that won't change: an ISP static IP, a fixed cloud IP, or a dedicated static IP for API whitelisting.

Keep reading