# How the Binance API key IP whitelist works

> An unrestricted Binance API key is treated as temporary: spot trading permission expires after 90 days without a whitelisted IP, and withdrawals can’t be enabled at all. Here’s how the whitelist works, which address to enter, and what -2015 is telling you.

- Source: https://papaproxy.net/blog/binance-api-key-ip-whitelist.php
- Published: 2026-07-31
- Author: Alex Young
- Category: Security & access · PapaProxy.net Blog

---

## Key takeaways

- Withdrawals cannot be enabled without an IP whitelist — that’s an official hard rule; spot trading works unrestricted, but the permission expires after 90 days without a whitelisted IP.
- Futures permission doesn’t require a whitelist; its usual failure is a key created before the futures account was opened.
- Whitelist your *egress* IP — check it with a one-line request through the same route your bot uses; NAT, cloud redeploys, and residential connections can all obscure it.
- A whitelist is only as reliable as the address in it: dynamic egress causes authentication failures, so production keys typically use one static address each.
- Error -2015 names three suspects: check egress against the whitelist first, then actual permissions through `apiRestrictions`, and then the key itself.
- Scope keys to the minimum, use one key per integration, rotate them regularly, prefer Ed25519, and keep secrets out of repositories.

## Which permissions require a whitelisted IP

The whitelist isn’t one switch — it interacts with each permission differently, and the differences are where keys break. The strictest rule concerns withdrawals: the official docs state it directly — you must apply the IP Access Restriction filter to enable withdrawals. No whitelist means no withdrawal permission. This limits a key that can move funds off the account to requests from the IP addresses you explicitly trust.

Spot trading sits one step softer, but with a countdown attached. A key can trade without any IP restriction temporarily. Leave the whitelist empty, and the spot trading permission lapses automatically after 90 days; the permission toggle switches off and the bot’s trading requests stop working. Add at least one trusted IP, and that expiration no longer applies. Binance also removes unrestricted keys that remain unused, so an idle key without a whitelist can have a shorter useful life.

Futures trading permission does not itself require a whitelist. Its constraints live elsewhere — the same permissions endpoint notes that the Futures API can’t be used if the key was created before the futures account was opened. This can affect users who enable futures later and continue using an older key. When you audit a key, pull its current state from the API key permissions endpoint (`GET /sapi/v1/account/apiRestrictions`): the response shows `ipRestrict`, `enableWithdrawals`, `enableFutures`, and the remaining permissions as booleans.

## Which IP actually goes on the list

The address Binance must see is your *egress IP* — the address from which your requests reach the internet — and that is often not the address shown locally. A machine behind NAT shows an internal `192.168.x.x` address while external services see the router’s public address. A cloud function or container platform may rotate egress addresses between deployments. A residential connection may also receive a different IP from its ISP, after which requests from the new address fail authentication.

The reliable way to find the right address takes one line, with one important condition: run it through the same route your bot uses. Checking from your laptop while the bot runs on a server identifies the wrong egress address.

PythonCopy code

```python
import requests

# Plain route — shows the egress IP of the machine itself:
print(requests.get("https://api.ipify.org").text)

# Through a proxy — shows the egress IP Binance will actually see:
proxy = {"https": "http://login:password@PROXY_IP:port"}
print(requests.get("https://api.ipify.org", proxies=proxy).text)
```

Whatever the second call prints when your bot’s proxy settings are active is the address that belongs in the whitelist. This leads to a structural requirement: a whitelist depends on the stability of every address in it. Dynamic egress causes authentication failures whenever the address changes. Production setups typically use one static egress address per key — a fixed IP that remains the same across reboots and deployments — and add that address once.

## What error -2015 means

Error code -2015 — `Invalid API-key, IP, or permissions for action` — names three possible causes without identifying which one occurred. Check them in order of likelihood.

Start with the IP, because it is common and easy to miss: your current egress address is not on the key’s whitelist. Run the check from the previous section through the exact route used by the failing code, then compare the output with the whitelist character by character. A changed residential IP, a redeployed container, or traffic leaving outside the proxy can all cause this mismatch. Second, check the permission. The key may not have the right required by the call: examples include a trading request from a read-only key, a futures request using a key created before the futures account, or a withdrawal request from a key without an IP restriction. Query `apiRestrictions` and inspect the relevant boolean. Third, check the key itself: a testnet key sent to production, a deleted or expired key, or whitespace introduced during copy and paste.

One logging practice makes -2015 much easier to diagnose: record the egress IP when the bot starts, next to the final four characters of the key. When the error occurs, that log immediately answers whether the expected key and route were in use.

## Security rules for every API key

The IP whitelist handles only one part of API key security. The remaining practices come from Binance’s security guidance and common failure modes in production.

Grant the minimum permissions. Reading, trading, and withdrawals are separate settings — enable only what the integration uses. A price tracker needs read access. A trading bot needs reading plus spot trading. Keep withdrawals disabled unless moving funds through the API is an explicit requirement. A leaked trade-only key can still cause losses through manipulated trades on illiquid pairs, which is why IP restrictions matter even when withdrawals remain disabled.

Use one key per integration. Give each bot, dashboard, and tax tool its own key instead of sharing one everywhere. This keeps permissions scoped, limits the impact of a compromised key, and lets you revoke one integration without interrupting the others. Review API keys regularly: open the API Management page, delete keys you can’t attribute, rotate the keys you retain, and prefer Ed25519 keys where your stack supports them. Binance recommends Ed25519, and its signatures are also faster.

Keep secrets out of code. Store keys in environment variables or a secrets manager, never in the repository. Public repositories are continuously scanned for exchange credentials, so treat any pushed secret as compromised. If a key may have been exposed, delete it first, create a replacement, and add its IP restrictions again.

These controls work best when each key uses one known static egress address. That is the setup our [proxies for Binance](/target/binance-proxy-server/) support: dedicated IPv4 addresses that remain static for the plan term, one per key or bot, with access available through IP whitelisting and HTTP, HTTPS, SOCKS4, and SOCKS5. Add the same proxy IP to the Binance whitelist so the trading permission remains active.