Learn / Exchange APIs

Binance API IP whitelist and the 90-day expiry

Figures on this page are as of 2026-09. Fees, limits and margin tiers change — check the venue's own docs before acting on a number.

A Binance API key with no IP whitelist loses its spot trading permission 90 days after activation, automatically. Reads keep working. Only orders start failing.

That is a strange failure to debug if you do not know it exists, and it is the most common reason working Binance automation stops working for no apparent reason.

The rule

From Binance’s 2021-07-26 announcement on API key permission rules: if a key does not have whitelisted IP addresses, the selected “Enable Spot & Margin Trading” permission is valid for 90 days from activation, and the system automatically unchecks the permission at expiry. You can manually re-enable it, after which an expiration prompt is shown against that permission.

An earlier 2021-07-08 announcement had set this at 30 days; the 90-day version superseded it.

Keys with whitelisted IPs do not expire this way. The rules apply to normal accounts, master accounts and sub-accounts. Keys created before the change do not trigger it automatically, though editing permissions surfaces a prompt if the conditions are met.

What it looks like when it happens

Distinctive enough to recognise:

  • Code that has worked for months, unchanged.
  • Market data still fine. Balances still fine.
  • Order placement returns -2015, “Invalid API-key, IP, or permissions for action”.
  • Nothing in your deployment changed.

The three-months-later timing is the giveaway. If your automation went live roughly a quarter ago and has just started refusing orders, check this first.

Confirm it by asking Binance directly:

GET /sapi/v1/account/apiRestrictions

If ipRestrict is false and enableReading is true while trading is being refused, this is almost certainly it.

The other reason to whitelist

Binance requires the IP Access Restriction filter to be applied in order to enable withdrawals at all. There is no unrestricted-IP withdrawal option.

This cuts both ways and both are useful:

  • If you want withdrawals on a key, you must whitelist.
  • If you do not — which is the right answer for automation — then leaving the key unrestricted means it structurally cannot withdraw. That is a stronger guarantee than remembering to leave a box unticked.

Binance has also tightened for unrestricted-IP HMAC keys specifically, recommending they hold no permission beyond reading and pointing users toward IPv4 restriction or self-generated Ed25519 / RSA keys for anything more.

Finding the address to whitelist

The whitelist needs the address Binance sees, which is frequently not the one you expect.

Check from the machine that makes the calls, not from your browser. On a server, a container, or a CI runner these are different networks.

curl -s https://api.ipify.org

Things that make this harder than it sounds:

  • Residential connections rotate. Home IPs change, sometimes on router reboot, sometimes on ISP whim.
  • Cloud instances change public IP on stop/start unless you have attached a static address.
  • VPNs and proxies egress from somewhere else — and from a pool, so the address differs per connection.
  • The whitelist takes IPv4. If your machine prefers IPv6, you may be connecting from an address you never whitelisted.
  • Containers and NAT. The egress address is the host’s or the NAT gateway’s, not the container’s.

For anything long-running, the practical answer is a static egress address — a cloud instance with a reserved IP, or a NAT gateway — rather than re-whitelisting whenever something changes.

A detail that catches people with dual-stack hosts

If the machine has both IPv4 and IPv6 connectivity, many HTTP clients prefer IPv6 when the DNS answer offers it. You then connect from an address that is not — and cannot be — on an IPv4 whitelist, and the symptom is an intermittent -2015 that follows no pattern you can see, because the preference can vary by process, by library, and by which resolver answered.

If a whitelisted setup fails inconsistently, force IPv4 in your HTTP client and see whether the problem disappears. That single test separates a network-layer cause from a permission-layer one, and it takes a minute.

If you cannot pin an address

Some setups genuinely cannot. In that case, know what you are accepting:

  • Trading permission will lapse every 90 days and need manual re-enabling. Put it in a calendar rather than discovering it live.
  • Withdrawals are unavailable on that key — again, usually fine.
  • A leaked key is usable from anywhere.
  • Binance’s guidance points toward keeping unrestricted HMAC keys read-only.

A reasonable arrangement is to split: an IP-restricted key on a fixed host for trading, and an unrestricted read-only key for whatever needs to run from wherever you happen to be.

FAQ

Why did my Binance API key stop trading after 90 days?

Because it has no IP whitelist. Binance automatically unchecks “Enable Spot & Margin Trading” 90 days after activation for keys without IP restriction. Reads keep working, so only order placement fails, usually with -2015. Re-enable the permission and add a whitelist so it does not recur.

How do I find the right IP to whitelist?

Query it from the machine that makes the API calls — for example curl -s https://api.ipify.org — rather than checking your browser’s address. Servers, containers and CI runners egress from different addresses than your workstation, and the whitelist expects IPv4.

Does whitelisting affect rate limits?

No — they are separate mechanisms. Rate limiting on Binance is weight-based per endpoint, reported through -1003, and escalates to an IP ban signalled by HTTP 418. Whitelisting controls which addresses may use the key at all.

Can I whitelist multiple IP addresses?

Yes, which is the usual approach when you have more than one machine or a small set of static egress addresses. It does not help with rotating residential connections or dynamic cloud IPs — for those you want a reserved address rather than a longer list.