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

CoTrading editorial team 2026-09-16 Updated: 2026-10-25

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

Binance error -2015 is REJECTED_MBX_KEY: a refusal involving the key, source IP or permissions. The official Spot error list does not identify which cause applies to your request. Sources on this page were checked on 2026-10-25; no live account or order was used for this review.

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

Do not infer that the signature passed because the response is -2015. The error list does not promise a validation order. These codes guide checks; they do not prove that every other authentication condition was satisfied.

The decision procedure

Use these checks to narrow the cause without placing a test order. The order below is a diagnostic sequence, not a measured ranking of cause frequency.

Step 1: ask Binance what the key can do

For a production key, Get API Key Permission documents this signed request, which needs the API-key header, timestamp and signature:

GET /sapi/v1/account/apiRestrictions

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

If it succeeds, inspect the relevant flags; success does not establish permission for every other endpoint. If it also returns -2015, an IP mismatch, wrong environment or invalid key can still be responsible. Continue with the environment and IP checks instead of treating the key as proven revoked.

Do not send this /sapi/* request to Spot Testnet: its supported API surface differs from production. Use matching testnet documentation and credentials; do not switch a test to live funds to make the permission check available.

Step 2: if the permission is missing, inspect its current status

Check API Management for disabled permissions, expiry notices and account restrictions. Reads continuing while orders fail can be consistent with lost trade permission, but does not establish why it changed.

An older version of this guide treated a historical 90-day unrestricted-IP permission rule as a current universal diagnosis. Its original announcement now redirects to the announcement index, so that rule was not reverified in this review. Use the current notice for your key type and account; do not enable extra permissions merely to clear an error.

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

If IP restriction is enabled, 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

Match the endpoint’s security type and product to the current permission response. The Wallet documentation lists separate Spot/Margin, Futures and transfer flags, with account-specific conditions. A successful balance query does not authorize a Futures order or a transfer. Check product documentation before changing an account or adding permissions.

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.

That prerequisite does not make an unrestricted key safe. A trade-enabled key can still cause losses; keep withdrawal and unnecessary transfer permissions disabled and verify the returned flags.

Prevention

Restrict source IPs where supported. Verify the actual egress address; an allowlist reduces exposure but does not make a leaked key harmless.
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?

Inspect permission status, account notices, source IP and environment. Loss of trading permission is one possibility, not a conclusion that follows from the elapsed time or error code alone. Do not assume a historical expiry rule applies to the current key.

What is the difference between -2015 and -2014?

-2014 reports an invalid key format. -2015 reports a key, IP or permission refusal; it does not reveal which validation checks completed successfully. Inspect the full response and configuration rather than inferring the cause from the code alone.

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.