Binance API error -2015, and how to tell which cause you have

2026-10-02

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.

Binance error -2015 is REJECTED_MBX_KEY, documented as “Invalid API-key, IP, or permissions for action.” One code, three unrelated causes — which is exactly why it is hard to debug.

Most write-ups tell you to “check your API key”. That is one third of the answer. Here is how to work out which third you have.

Rule out the ones that are not -2015 first

Binance has adjacent codes that people conflate with this one. If you are seeing any of these, you have a different problem:

Code	Name	Meaning
`-2014`	`BAD_API_KEY_FMT`	“API-key format invalid.” The key string is malformed — whitespace, truncation, a newline from copy-paste
`-1022`	`INVALID_SIGNATURE`	“Signature for this request is not valid.” Your signing is wrong, not your key
`-1021`	`INVALID_TIMESTAMP`	Timestamp outside `recvWindow`, or ahead of server time — a clock problem

-2015 means the key parsed fine and the signature was acceptable. The request got far enough to be evaluated and then refused.

The decision procedure

Work through these in order. It is ordered by how often each is the answer and how cheap it is to check.

Step 1: ask Binance what the key can do

Do not rely on what you remember ticking. Call:

GET /sapi/v1/account/apiRestrictions

It returns the key’s actual state, including ipRestrict, createTime, enableReading, enableWithdrawals, enableInternalTransfer, enableMargin, enableFutures and permitsUniversalTransfer.

This single call resolves most -2015 cases, because it distinguishes “permission missing” from “IP wrong” immediately. If this call itself returns -2015, the key is wrong or revoked — skip to step 4.

Step 2: if the permission is missing, check whether it expired

This is the cause people do not know to look for.

A key with no IP whitelist has its “Enable Spot & Margin Trading” permission automatically switched off after 90 days from activation. Binance’s 2021-07-26 announcement describes the system unchecking the permission at expiry; it can be manually re-enabled. (An earlier announcement set this at 30 days; 90 superseded it.)

Keys with whitelisted IPs do not expire this way.

So the signature of this cause is distinctive and easy to recognise: code that worked for months suddenly returns -2015 on order placement, while reads keep working. If enableReading is true and trading is refused on a key with ipRestrict: false, this is almost certainly it.

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

Step 3: if the permission is present, check where you are calling from

If ipRestrict is true, the whitelist has to contain the address Binance actually sees. Things that break this without you changing anything:

A residential IP that rotates.
Cloud instances that change public IP on restart.
A VPN or proxy that egresses from a different address than you expect.
IPv6 versus IPv4 — the whitelist takes IPv4.
Containers or CI runners egressing through a NAT you did not account for.

Check your actual egress address from the machine making the call, not from your browser. They are frequently different.

Step 4: the key is wrong, revoked, or from the other environment

Less common but worth eliminating:

The key was deleted or regenerated and something is still using the old one.
Testnet credentials pointed at production, or the reverse. Testnet lives at https://testnet.binance.vision/api/v3/ and its keys do not exist on api.binance.com.
Two keys in the environment and the wrong one is being picked up.
The key belongs to a sub-account and the call targets the master, or vice versa.

Step 5: the endpoint needs a permission you have not thought about

Futures endpoints need enableFutures, and the docs note this is unusable if the key predates opening the futures account or if portfolio margin is enabled. Margin needs enableMargin, which only becomes adjustable after a cross-margin transfer completes. Both produce a permission refusal on an endpoint you consider ordinary.

The special case: withdrawals

If you are trying to enable withdrawals and cannot, this is not a bug. Binance requires the IP Access Restriction filter to be applied in order to enable withdrawals at all. There is no unrestricted-IP withdrawal option. The IP filter is a precondition for the permission, not a setting alongside it.

For automation this is mostly good news: it means a key without IP restriction structurally cannot withdraw.

Prevention

Whitelist an IP. It removes the 90-day expiry, eliminates the largest cause of the mystery version of this error, and bounds what a leaked key is worth.
Check permissions programmatically at startup. A process that verifies its own key on boot fails immediately and legibly, instead of at the moment it first tries to trade.
One key per consumer. When -2015 appears you want to know which component hit it.
Log which environment you are in. Testnet-versus-production mix-ups are embarrassing to diagnose and trivial to prevent.

FAQ

Why did my Binance API key stop working after a few months?

Most likely the 90-day expiry on spot trading permission for keys with no IP whitelist. Binance automatically unchecks “Enable Spot & Margin Trading” at expiry; reads continue to work, so the symptom is that order placement starts returning -2015 while everything else looks fine. Re-enable the permission, and add an IP whitelist so it does not recur.

What is the difference between -2015 and -2014?

-2014 is BAD_API_KEY_FMT — the key string itself is malformed, usually whitespace or truncation from copy-paste. -2015 is REJECTED_MBX_KEY, which means the key was well-formed and was then refused for being unknown, coming from a disallowed IP, or lacking the permission for that endpoint.

How do I check my key’s permissions without the dashboard?

GET /sapi/v1/account/apiRestrictions returns the current flags, including ipRestrict, enableReading, enableWithdrawals, enableMargin and enableFutures. This is more reliable than memory and is worth calling at process startup.

Can I enable withdrawals without an IP whitelist?

No. Binance requires the IP Access Restriction filter to be applied before withdrawals can be enabled. For an automation key this is a useful property rather than an obstacle — without an IP whitelist, the key cannot withdraw at all.