Exchange API key security checklist
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.
Ordered by what survives things going wrong. The items near the top hold even if your code is buggy, your dependencies are compromised, or a third-party server turns out to be something other than you thought. The items near the bottom are good practice that assumes components behave.
1. Scope the credential
☐ Start read-only. Most programmatic use — monitoring, exposure, reporting — needs no write access. A leaked read key is an information disclosure, not a financial event.
How each venue does it:
| Venue | Mechanism |
|---|---|
| Binance | Permission flags; enableReading alone |
| Bybit | Permission scopes on the key |
| Alpaca | Access Controls: Read only / Full access / Custom per scope |
| IBKR | Read-Only API application setting — on by default |
| Hyperliquid | No API key; agent wallets sign, and cannot express fund moves |
☐ On IBKR, leave Read-Only API ticked unless you are placing orders. Global Configuration → API → Settings. It “allows viewing of market data and account information, but blocks any type of trading activity”, is available in TWS 950+, and is enabled by default. It is the only default-safe configuration in this table — do not switch it off to silence an error you have not diagnosed.
☐ On Alpaca, use Custom rather than Full access when you need partial write. You can leave watchlists writable while trading stays read-only.
☐ One key per consumer.
A key shared between a bot, a dashboard and a notebook gives you three paths to
one permission set and no attribution when something goes wrong. It also causes
real operational problems — on Bybit classic accounts, shared keys contribute to
10003, “Too many sessions under the same UID”.
2. Bound what a leak is worth
☐ Understand your venue’s withdrawal model before assuming you disabled it. On Binance, withdrawals cannot be enabled on a key without IP access restriction. So an unrestricted key structurally cannot withdraw — a stronger statement than remembering to untick a box.
☐ Check the transfer flags, not just withdrawals.
enableInternalTransfer and permitsUniversalTransfer move value between
accounts without sending it to an external address. Automation rarely needs
either.
☐ Bind an IP where supported.
Binance and Bybit both enforce it — Bybit’s 10010, “Unmatched IP, please check
your API key’s bound IP addresses”, is its signature. On Binance it has a second
effect: without a whitelist, spot trading permission is automatically
unchecked 90 days after activation. Budget for that or avoid it.
☐ Consider a sub-account with bounded funds. Stronger than any permission flag, because it limits damage from correct-but-wrong behaviour as well as from compromise. Particularly worth it for third-party software holding your keys.
3. Verify rather than remember
☐ Assert permissions at process startup.
On Binance, GET /sapi/v1/account/apiRestrictions returns ipRestrict,
createTime, enableReading, enableWithdrawals, enableInternalTransfer,
enableMargin, enableFutures and permitsUniversalTransfer. A process that
refuses to start when enableWithdrawals is true converts a silent exposure
into an immediate failure.
☐ Know your key’s creation date.
It determines whether Binance’s 90-day expiry is imminent, and on Bybit UTA it
is the input to key expiry (10003 on spot, 33004 on derivatives).
☐ Watch for permissions that cannot be set yet.
Binance’s enableMargin only becomes adjustable after a cross-margin transfer
completes, and enableFutures is unusable if the key predates opening the
futures account or if portfolio margin is enabled. Both read as bugs and are
not.
4. Handle the credentials themselves
☐ Know where they are read from, and who else can read that. ☐ Check nothing logs them. Verbose and debug modes are where this lives; run against testnet credentials with logging on and grep the output for the key. ☐ Treat the OKX passphrase as a credential. It is a third secret, you chose it, and it is not recoverable — losing it means replacing the key. ☐ Record Alpaca secrets at generation. Shown once, not retrievable. ☐ Keep them out of anything synced or versioned. Dotfiles repos and MCP client config files are the usual accidents.
5. Separate environments
☐ Prefer venues where testnet is a different hostname.
Binance (testnet.binance.vision), Bybit (api-testnet.bybit.com), Hyperliquid
(api.hyperliquid-testnet.xyz) and Alpaca (paper-api.alpaca.markets) all
separate by host, so a mix-up produces an auth error rather than a live trade.
☐ On OKX, treat the demo header as a hazard.
Demo trading uses the same host with x-simulated-trading: 1. A dropped
header means production. Assert it is present rather than trusting it.
☐ On IBKR, log which port you connected to. 7497/4002 is paper, 7496/4001 is live, and the ports are the only thing distinguishing them in your code.
☐ Never put live credentials in a development environment to “just test something”.
6. Operational
☐ Rotate on any suspicion. Rotation is cheap; investigation is not. ☐ Practise revocation once, calmly, before you need it. ☐ Review keys on a schedule. Setups drift — the configuration you reasoned about in March is not what is running in September. ☐ Remove keys for decommissioned services. Orphaned credentials with live permissions are a standing risk nobody owns.
What this does not cover
Account-level security — 2FA, withdrawal address whitelists, anti-phishing codes — which matters and is a different layer. Nor does it cover whether any particular third-party software is trustworthy; a checklist cannot substitute for that judgement, it can only bound the consequences of getting it wrong.
FAQ
What is the single most important item?
Scoping the credential. Everything else assumes your software behaves as expected; the permission set on the key is enforced by the venue regardless of what runs on your machine. A read-only key makes most of the rest of this list precautionary rather than load-bearing.
Which venue is safest by default?
IBKR, because its Read-Only API setting blocks all API trading and is enabled by default from TWS 950 onward. Every other venue here issues a key with the permissions you selected, active immediately. It is the only one where doing nothing leaves you unable to trade.
Do I need an IP whitelist if my key cannot withdraw?
It still helps — it bounds a leaked key to one address. On Binance there is an additional reason: without a whitelist, spot trading permission is automatically switched off after 90 days, which produces a confusing outage if you are not expecting it.
How does any of this apply to Hyperliquid, which has no API keys?
Through the agent-wallet model. A master account approves an API wallet to sign on its behalf, and the signing scheme gives that wallet no way to express moving the master’s funds, since fund-moving actions carry no account address. It behaves like trade-only, but Hyperliquid has not documented it as a guarantee — verify it on your own setup rather than assuming.