How to Manage Binance API Keys: Minimum-Permission Setup and Regular Review

A Binance API Key is an access token for programmatic trading, market data subscriptions, and third-party strategy platforms. Log in to the Binance Official Site → [API Management] and create a Key — by default it only has [Read] permission; [Spot Trading], [Futures Trading], and [Withdrawals] each have to be checked individually to enable them. This time we set up 5 separate Keys for different purposes, each with minimum permissions and an IP binding, so that even a single-point leak keeps the maximum damage contained to that one Key's permission scope.

The most important rule of discipline: never grant withdrawal permission to an API Key unless your program genuinely needs to withdraw automatically. 99% of programs never need it, but once it's enabled, a leaked Key means the coins get emptied out directly. Even when you do enable it, you must pair it with a whitelist (see How to Set Up Binance's Withdrawal Whitelist: Adding Addresses and Cooldown Details).

What Each of the 5 Permission Toggles Does

Here's the full table of Binance API Key permission options and our recommended setting strategy:

Permission	What It Does	Risk	Recommendation
Enable Reading (read access)	Check market data, balances, orders	Very low	Always check
Enable Spot & Margin Trading	Place orders, cancel orders	Medium (worst case: churned by adverse orders)	As needed
Enable Futures (futures trading)	Place futures orders, adjust leverage	Medium-high (leverage amplifies losses)	As needed
Enable Withdrawals	On-chain withdrawal to a specified address	Extremely high (funds can be moved out directly)	Almost never check
Permits Universal Transfer (inter-account transfer)	Transfer between Spot / Futures / Funding accounts	Low	As needed

Read permission is granted by default — no need to check it. Check spot and futures permissions based on what your program actually does. Only check withdrawal permission as an absolute last resort, and once checked, it must be paired with a bound withdrawal address (this step happens in the whitelist settings, not the API Key settings).

Step 1: Creating an API Key

The [API Management] entry point is under [Account Center] → [API Management], and it's in the same path on the app. Click [Create API] → choose [System generated] or [Self-generated]:

Type	Difference	Recommended Use
System generated	Binance generates the secret; you can only view it once	99% of use cases
Self-generated	Uses an Ed25519/RSA public key; the secret never gets uploaded at all	High-security scenarios

Regular users should just choose [System generated]. Give the Key a name (under 30 characters, e.g. bot-spot-grid-arb), then click [Create]. The system will ask for a 2FA code, email verification code, and SMS code (if bound) — only after all three pass does it generate the Key.

Once generated, it displays the API Key (public key, 64 characters) and Secret Key (private key, 64 characters). The Secret Key is only shown this one time — close the page and it's gone for good. Immediately copy the Secret into a password manager or encrypted note; if you lose it, your only option is to delete the Key and create a new one.

Step 2: Checking Permissions

A newly created Key has read-only permission by default. To enable trading permissions, click [Edit restrictions] → check the relevant permissions → enter your 2FA code to confirm. Every permission change triggers a 2FA plus email verification.

Here's how we configured our 5 Keys:

Key Name	Purpose	Permissions	IP Restriction
bot-spot-grid	Spot grid trading bot	Read + Spot Trading	Restricted to 1 IP
bot-futures-trend	Futures trend-following strategy	Read + Futures Trading	Restricted to 1 IP
tax-export	Tax reporting export tool	Read-only	Restricted to 2 IPs
dashboard-only	Personal monitoring dashboard	Read-only	Unrestricted (used only on home WiFi)
manual-transfer	Manual inter-account transfer tool	Read + Universal Transfer	Restricted to 1 IP

None of the 5 has withdrawal permission enabled. If any one of them ever leaks, the worst-case damage is losses from adverse orders (still bounded by that Key's spot/futures permissions) — the coins themselves can't be moved out.

Step 3: Binding an IP Whitelist — the Critical Step

At the bottom of the [Edit restrictions] page is [Restrict access to trusted IPs only]. Click it and enter IP addresses (comma-separated for multiple, up to 30).

Why binding an IP is mandatory:

• Even if the API Key and Secret leak, the attacker's server IP won't be on the whitelist
• Binance's servers reject every request from any non-whitelisted IP, returning a -2015 error
• It's effectively an extra "geographic location" layer of authentication

The cost of not binding an IP:

• A Key without an IP restriction is forcibly invalidated by Binance after 90 days (this has been a hard rule since 2024)
• A Key with an IP bound doesn't auto-expire and can be used indefinitely

How to find your server's IP:

• Self-hosted bot: run curl ifconfig.me on that machine to see the outbound IP
• Cloud functions or PaaS: check the fixed outbound IP your provider offers (many PaaS providers don't have a fixed outbound IP — you'll need to configure a separate NAT)
• Running at home: your broadband's public IP (a dynamic IP that changes daily is a hassle — home binding isn't recommended)

If your program runs in a dynamic IP environment (e.g. home broadband, working remotely), skipping the IP binding means it force-expires after 90 days, while binding it means it'll fail whenever your IP changes. In that situation, either move to a VPS (fixed IP) or switch to an internal-network tunneling solution.

Of our 5 Keys, 4 had IPs bound this time. The remaining one, dashboard-only, is fine without one since it's read-only and already has minimal permissions.

Step 4: Testing Whether the Key Works

After creating it, test it with curl:

curl -H "X-MBX-APIKEY: YOUR_API_KEY" \
  https://api.binance.com/api/v3/account?timestamp=1234567890&signature=xxx

If it returns account information, the Key is working correctly. If it returns:

Error Code	Meaning	Fix
-2014	Invalid API Key	Check whether the Key was copied in full, with no extra spaces
-2015	IP not on the whitelist	Check your current outbound IP and add it to the whitelist
-1022	Signature error	Check the Secret Key and your signing algorithm
-1021	Timestamp outside the window	Server clock is out of sync — check the time
-2010	This permission isn't enabled	This Key doesn't have the relevant permission checked — go to [Edit] and add it
-4007	Withdrawal address not whitelisted	Only encountered on withdrawal APIs — add the address to the whitelist

The one people trip over most is -2015, IP not whitelisted, because a lot of people don't actually know their real outbound IP (e.g. they're using a VPN, Cloudflare, or a corporate network). Opening [API Management] in the Official Binance App also shows [Last Access IP], which you can compare against what you thought your IP was.

Step 5: Regular Review + Rotation

Do an API Key checkup every 90 days:

1. List every Key: The [API Management] main page shows every Key's creation date, last access time, permissions, and IP restriction at a glance.

2. Flag suspicious Keys:

• No longer sure which program it's for → delete it
• No [last access] record for 30 days → delete it
• Missing an IP binding → add one, or delete it
• Permissions exceed what's actually needed → scale them down to the minimum

3. Proactively rotate: For important Keys (ones with access to significant assets), we recommend re-creating them proactively every 90 days: delete the old Key → create a new one → update your program → verify it works → done. This process briefly takes your program offline for 1-5 minutes, so schedule it during a low-activity window.

4. Checks before deletion: Deleting an API Key takes effect immediately and cannot be undone. Before deleting, confirm:

• This Key isn't referenced by any currently running program
• This Key isn't used in any cron job or scheduled task
• There's no leftover copy in a Git repository's .env or config files (these should already be in .gitignore, but double-check anyway)

Emergency Response to a Leaked API Key

If you discover a Key may have leaked (e.g. accidentally pushed to a public Git repository), immediately:

1. First second: Delete the Key in [API Management]
2. Second second: Check all of the Key's transactions from the last 24 hours for suspicious orders
3. Third second: If withdrawal permission was ever enabled, check for suspicious withdrawals (should have been blocked by the whitelist, but check anyway)
4. Fourth second: Change your account password and reset 2FA (even without evidence other credentials leaked too, do a full clean sweep anyway)
5. Afterward: If it was already pushed to Git, just deleting the Key isn't enough — you also need to scrub the secret from the Git history using git filter-branch or a tool like BFG, otherwise someone can dig it back out of the commit history

GitHub and GitLab both run automatic secret-scanning services, and if a Binance API Secret gets pushed to a public repo, Binance usually receives a platform notification within hours and proactively invalidates that Key — but that's only a safety net, not something you should rely on.

Pitfalls of Using API Keys With Third-Party Platforms

A lot of third-party strategy platforms, tax tools, and portfolio management tools ask you to enter an API Key. The rule of thumb:

Third-Party Type	What Permission to Grant	Red Flag
Tax reporting export tool	Read-only	Asks you to enable withdrawals → run
Portfolio monitoring dashboard	Read-only	Asks you to enable trading → think carefully
Copy-trading / signal / strategy platform	Read + Spot/Futures Trading	Asks you to enable withdrawals → absolutely run
Leverage funding / lending tools	Don't touch these at all, skip them	Anything requiring withdrawals — run

The red line: if a third-party tool confidently demands withdrawal permission, 99% of the time they're trying to walk off with your funds. Tax tools, monitoring, and copy-trading never need withdrawal permission — at most they need read access plus trading permission.

This time we granted a futures copy-trading platform [Read + Futures Trading]. When they asked for [Withdrawals], we refused, and they accepted it anyway — proof that this permission was optional to begin with, and if they truly required it, that's exactly when you should walk away.

FAQ

Q: Which is more sensitive, the API Key or the Secret Key? A: The Secret Key is more sensitive. The API Key is just a user identifier that can be shared, while the Secret Key is the signing key — leaking it means all your permissions can be exploited. Never write the Secret into any email, chat, or issue tracker.

Q: How should I securely store an API Key and Secret? A: Locally, use a password manager like 1Password, Bitwarden, or KeePass. On servers, use environment variables plus Docker secrets or a K8s Secret — never hardcode them in your code. Your Git repository should always have .env in .gitignore.

Q: Can I rename an API Key after getting it from Binance? A: Yes. [API Management] → find the Key → [Edit restrictions] lets you rename it. Renaming doesn't affect the Key/Secret itself — it's just a label for your own reference.

Q: What's the maximum number of API Keys? A: Up to 30 API Keys per account. 5-10 is usually enough for splitting purposes; the 30 limit is designed for large numbers of sub-accounts and quant teams.

Q: Is there a difference between a Sub-Account's API and the main account's API? A: Yes. A sub-account's API can only operate on assets within that sub-account and can't touch the main account. Sub-accounts are also isolated from each other. This makes sub-accounts particularly well-suited to strategy isolation and risk isolation, and quant teams use them heavily.

Q: Are there rate limits on API Key access? A: Yes. Every Binance endpoint has a weight limit — simple endpoints have a weight of 1, complex ones up to 20. Each IP gets a total budget of 1200 weight per minute, and exceeding it returns a -1003 rate-limit error. Endpoints like checking your balance or querying orders are lightweight, and placing orders is too; querying all klines or all trading pairs will burn through your budget fast.

Q: Will historical trading records be lost after I delete an API Key? A: No. Trading records and order history belong to the account level, independent of which Key placed the order. Deleting a Key just revokes that access credential — all the data in the account is preserved.

Q: Does the whitelist IP field support IPv6? A: Yes. Binance's API whitelist accepts both IPv4 and IPv6 addresses, entered the same way as normal. If your server has both v4 and v6 outbound addresses, we recommend adding both.

Q: What does the automatic 90-day API expiration mean? A: An API Key without an IP whitelist bound will automatically expire 90 days from its creation date and need to be recreated. A Key with an IP bound doesn't auto-expire. This rule is in Binance's official announcements and has been in effect since 2024, mainly to clean up long-unmaintained Keys.