Disabling withdrawals on a Binance API key
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.
On Binance, withdrawals cannot be enabled on an API key without applying the IP Access Restriction filter. The filter is a precondition for the permission, not a setting beside it.
Which means the usual advice — “remember to disable withdrawals on your trading key” — describes the wrong mechanism. There is nothing to remember to disable. If your key has no IP whitelist, withdrawals are not available to enable in the first place.
That distinction matters more than it sounds, and it is worth being precise about.
Why the difference matters
“I disabled withdrawals” is a claim about a past action. It depends on your memory, on nobody having changed it since, and on you having understood the interface correctly at the time.
“This key cannot withdraw because it has no IP restriction and Binance will not enable withdrawals without one” is a claim about the current state of the system. It does not depend on anyone’s memory, and it is verifiable.
For a key you are handing to automation — a bot, an MCP server, a script — the second kind of statement is what you want. Especially so when the software holding the key is code you did not write.
Verifying rather than remembering
GET /sapi/v1/account/apiRestrictionsReturns, among others, ipRestrict, enableReading, enableWithdrawals,
enableInternalTransfer, enableMargin, enableFutures and
permitsUniversalTransfer.
Assert on this at process startup. A trading process that refuses to run when
enableWithdrawals is true turns a configuration mistake into an immediate,
noisy failure rather than a latent exposure.
It is worth checking the transfer flags too. enableInternalTransfer and
permitsUniversalTransfer do not withdraw to an external address, but they do
move value between accounts, and an automation key rarely needs either.
The assertion itself is small enough that there is no excuse for skipping it:
r = client.get_api_key_permission()
assert r["enableReading"], "key cannot read"
assert not r["enableWithdrawals"], "key can withdraw — refusing to start"
assert not r["enableInternalTransfer"], "key can move funds between accounts"
assert not r["permitsUniversalTransfer"], "key permits universal transfer"
if not r["ipRestrict"]:
# Not fatal, but this key's spot trading permission will lapse at 90 days.
log.warning("no IP restriction: trading permission expires %s",
"90 days after activation")The ipRestrict warning is the part that earns its place over time. It turns
the 90-day expiry from a mystery outage into a line in your logs that was there
all along.
The trade-off you are actually making
Since the IP filter gates withdrawals, you are choosing between two arrangements and both are defensible:
No IP whitelist. Withdrawals are structurally unavailable. In exchange, the key’s spot trading permission expires 90 days after activation and must be manually re-enabled — Binance automatically unchecks it for unrestricted-IP keys. Binance additionally recommends that unrestricted-IP HMAC keys carry no permission beyond reading.
With IP whitelist. Trading permission does not expire, and a leaked key is only usable from your address — but withdrawals become something you must deliberately leave off, which returns you to a checkbox.
The arrangement that gets the best of both is to split by purpose: an IP-restricted key on a fixed host for trading, and a separate read-only key for anything that needs to run from a changing address. Neither one ever needs withdrawal permission.
What this does not protect you from
Being precise about the boundary, because it is narrower than “my funds are safe”:
- A trade-enabled key can still lose you money by trading badly. Withdrawal permission is about exfiltration, not about losses.
- Internal and universal transfers are separate flags. Check them.
- Nothing here protects the account itself — account-level security (2FA, withdrawal address whitelists, anti-phishing code) is a different layer and still matters.
The claim is narrow and worth having: a leaked key that cannot withdraw cannot drain the account. That is the single largest reduction in blast radius available, and on Binance you can get it structurally.
The general principle
Prefer boundaries that are properties of the system over boundaries that are records of your intentions.
A permission that cannot be granted beats a permission you turned off. A key scoped to one purpose beats a key you are careful with. A limit enforced in code beats a limit written in a prompt. In each case the difference shows up at the same moment: when something unexpected happens and nobody is watching.
FAQ
How do I disable withdrawals on a Binance API key?
Usually you do not have to. Binance requires the IP Access Restriction filter to
be applied before withdrawals can be enabled at all, so a key without an IP
whitelist cannot withdraw. If your key does have a whitelist, withdrawals become
a permission you can grant — leave it off, and confirm with
GET /sapi/v1/account/apiRestrictions.
Can an API key drain my Binance account?
Only if it has withdrawal permission, which requires an IP whitelist to enable. A trade-only key cannot move funds off the exchange. It can still lose money by trading, which is a different risk managed by position limits rather than by key permissions.
Do internal transfers count as withdrawals?
No — they are separate flags. enableInternalTransfer covers master and
sub-account transfers and permitsUniversalTransfer covers universal transfer.
Neither sends funds to an external address, but both move value, and automation
rarely needs either. Check them alongside enableWithdrawals.
Is this the same on other exchanges?
No, and do not assume it. Binance’s coupling of withdrawal permission to IP restriction is specific to Binance. Other venues expose withdrawal permission as an independent toggle, and Hyperliquid has no API keys at all — it uses agent wallets, where the constraint is structural rather than a permission.