Binance API key permissions

2026-10-06

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’s permissions are a set of flags, and you can ask Binance what they currently are rather than trusting what you remember ticking. That second part is the useful habit, because the flags do not always stay where you put them.

The flags

GET /sapi/v1/account/apiRestrictions returns the key’s actual state:

Field	What it controls
`enableReading`	Account and market data reads
`enableWithdrawals`	Withdrawals — see the constraint below
`enableInternalTransfer`	Transfers between master and sub-accounts
`enableMargin`	Margin endpoints
`enableFutures`	Futures endpoints
`permitsUniversalTransfer`	Universal transfer
`ipRestrict`	Whether an IP whitelist is applied
`createTime`	When the key was created

Two of these have caveats that are not obvious from the name.

enableMargin only becomes adjustable after a cross-margin account transfer has completed. Until then you cannot turn it on, which reads as a bug and is not.

enableFutures is documented as unusable if the key predates opening the futures account, or if portfolio margin is enabled. A key created before you opened futures will not work for futures even with the flag set — regenerate it.

The two rules that make Binance different

Withdrawals require IP restriction

You cannot enable withdrawals on a key without applying the IP Access Restriction filter. It is a precondition for the permission, not a setting beside it.

For an automation key this is useful rather than restrictive: a key with no IP whitelist structurally cannot withdraw. That is a stronger statement than “I remembered to leave withdrawals off”, and it does not depend on your memory.

Trading permission expires on unrestricted keys

Per Binance’s 2021-07-26 announcement: if a key has no whitelisted IP, the “Enable Spot & Margin Trading” permission is valid for 90 days from activation, after which the system automatically unchecks it. It can be manually re-enabled, at which point the expiry is shown against the permission. (An earlier 2021-07-08 announcement set this at 30 days; 90 superseded it.)

Keys with whitelisted IPs do not expire this way. The rules apply to normal accounts, master accounts and sub-accounts.

Binance has since gone 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 anything more.

The pattern across both rules is consistent: Binance is steering you toward IP-restricted keys, and the path of least resistance if you ignore that is a key that silently stops being able to trade.

Choosing permissions

Reading only. The right default. Most programmatic use — monitoring, exposure calculation, reporting — needs nothing else, and a leaked read key is an information disclosure rather than a financial event.

Reading plus spot trading. Add when you actually intend to place orders. Add an IP whitelist at the same time, or you are signing up for the 90-day expiry.

Futures or margin. Only if used, and verify the key was created after the relevant account was opened.

Withdrawals. Not on a key used by automation. The IP requirement makes this partly self-enforcing, which is a good reason to leave automation keys unrestricted-IP only if they also cannot trade — and IP-restricted otherwise.

Verify at startup

A process that checks its own key on boot fails immediately and legibly rather than at the moment it first tries to trade:

GET /sapi/v1/account/apiRestrictions

Assert what you expect — enableReading true, enableWithdrawals false, ipRestrict true if you set one — and refuse to start if it does not match. This catches expired trading permission, a rotated key, and a testnet-versus-production mix-up, all before they become a live incident.

Sub-account keys follow the same rules

The permission rules apply to normal accounts, master accounts and sub-accounts alike, which is worth stating because sub-accounts are often used precisely to isolate automation — and people assume the isolation brings different rules with it. It does not. A sub-account key with no IP whitelist expires its trading permission on the same 90-day schedule, and cannot enable withdrawals for the same reason.

What sub-accounts do give you is a genuine blast-radius reduction: a key scoped to a sub-account can only affect that sub-account’s balances. If you are running automation you do not fully trust — which includes any third-party MCP server — funding a sub-account with a bounded amount is a stronger control than any permission flag, because it limits the damage from correct-but-wrong behaviour as well as from compromise.

Note that enableInternalTransfer covers master-to-sub transfers, so an automation key on a sub-account should not have it.

Signing note

Binance supports HMAC-SHA256 (signature case-insensitive), RSA with PKCS#8 keys (case-sensitive) and Ed25519 (case-sensitive, documented as recommended for best performance). The key type interacts with the permission rules above — the tightened restrictions on unrestricted-IP keys apply specifically to HMAC keys.

FAQ

How do I check a Binance key’s permissions programmatically?

GET /sapi/v1/account/apiRestrictions returns the current flags, including ipRestrict, enableReading, enableWithdrawals, enableMargin and enableFutures. Calling it at process startup and asserting the expected values turns a silent misconfiguration into an immediate, obvious failure.

Why can’t I enable withdrawals on my key?

Because Binance requires the IP Access Restriction filter to be applied first. There is no unrestricted-IP withdrawal option. If you genuinely need withdrawals, add an IP whitelist; if this is an automation key, the inability to enable them is a feature.

Why did my key stop being able to trade?

If it has no IP whitelist, most likely the 90-day expiry: Binance automatically unchecks spot and margin trading 90 days after activation for unrestricted-IP keys. Reads continue working, so the symptom is that only order placement starts failing, typically with -2015.

My futures calls fail even though the futures flag is set.

Check when the key was created. Binance documents enableFutures as unusable if the key predates opening the futures account, and also if portfolio margin is enabled. Regenerating the key after the account exists is the usual fix.