API key permissions compared across exchanges and brokers

CoTrading editorial team 2026-09-23

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

Every venue lets you create a credential that can read but not trade. That is where the similarity ends. Whether withdrawals can be switched on at all, whether an IP whitelist is a condition or a suggestion, whether an idle key quietly stops working, and whether there is a key in the first place all differ, and each difference changes how a key fails in production.

This page puts six venues side by side for anyone configuring credentials for a bot, an MCP server or a monitoring job. Every cell comes from that venue’s own documentation; where we could not find a rule, the cell says so. It ends with what to put in code so a permission problem shows up at startup, not at the first order.

The matrix

Venue	Permission model	Withdrawal gating	IP binding	Expiry	Sub-accounts
Binance	Flags on the key: `enableReading`, `enableWithdrawals`, `enableInternalTransfer`, `enableMargin`, `enableFutures`, `permitsUniversalTransfer`	Withdrawals cannot be enabled without IP restriction	Optional, but a precondition for withdrawals	No IP whitelist: spot and margin trading is unchecked 90 days after activation	The same rules apply to sub-accounts
Bybit	Permission scopes on the key; a refusal is `10005`	Not documented in our fact card	Supported and enforced (`10010`); whether any permission requires it, we did not find	Expired keys have their own codes; the expiry rule itself, we did not find	Exist; key rules for them are not documented in our card
OKX	Read, Trade, Withdraw; one or more per key	Withdraw is its own permission; we did not find an IP precondition	Strongly recommended, not required; several IPs and ranges allowed	Unbound keys holding Trade or Withdraw expire after a period of inactivity	Each sub-account has its own User ID
Hyperliquid	No API key. The master approves API (agent) wallets to sign for it or its sub-accounts	The docs do not say whether an API wallet can sign withdrawals (see below)	We did not find one	Optional `valid_until` on named agents; default expiry not documented	No private keys; acted on via `vaultAddress`
Alpaca	Access Controls: Read only, Full access, or Custom per scope	Not documented in our fact card	Whether keys support IP allowlisting, we did not find	Set at creation: Never, 1 week, 30 days, 90 days, 6 months, 1 year or a custom date	Each account has separate credentials
IBKR (TWS API)	No key. Read-Only API is an application setting, on by default	Not part of the TWS API as documented	Trusted IPs in TWS; untrusted IPs are denied without a prompt	No credential to expire; the Client Portal gateway needs daily re-authentication	Not documented in our fact card

Where the venues actually differ

Binance: the IP whitelist is load-bearing

On Binance the whitelist gates two things.

Withdrawals. Binance’s wallet API docs state that the IP Access Restriction filter must be applied in order to enable withdrawals. A key without a whitelist cannot have withdrawals switched on at all — see disabling withdrawals on a Binance key.

Trading lifetime. Per Binance’s 2021-07-26 announcement, a key with no whitelisted IP keeps “Enable Spot & Margin Trading” for 90 days from activation, after which the system unchecks it. It can be re-enabled by hand. Keys with a whitelist do not expire this way.

The symptom is distinctive: reads keep working and orders start returning -2015. The -2015 decision procedure and the IP whitelist page cover the fix.

OKX: withdrawal is a checkbox, and idle keys expire

OKX offers three permissions, Read, Trade and Withdraw, and “One or more permission can be assigned to any key”. IP binding is strongly recommended but not required, so an unbound OKX key can hold Withdraw.

The counterweight is the inactivity rule. A key that is not IP-bound and holds Trade or Withdraw expires after a period without use; the window is a policy value on OKX’s API-key-creation section, so check it there. For automation:

Only calls to endpoints that require API-key authentication count as use.
On WebSocket, only the login counts. By that rule, a process that logs in once and then holds a private stream open is not generating use.

Demo-trading keys do not expire under this rule. OKX also adds a third credential, the passphrase, which it stores only as a salted hash and cannot recover — see the OKX passphrase.

Bybit: the error codes are clearer than the scope list

Our Bybit card does not capture the scopes as Bybit’s UI presents them, or whether any of them requires IP binding. What is documented is the split between failures:

10005 — “Permission denied, please check your API key permissions.”
10010 — “Unmatched IP, please check your API key’s bound IP addresses.”
10003 over REST — an invalid key, most often one created for a different environment than the host.
An expired key is -2015 on spot and 33004 on derivatives.

Binance folds key, IP and permission into -2015; Bybit separates them — see 10005 and 10010.

Hyperliquid: the question changes shape

There is no key to scope. A master account approves an API wallet (also called an agent wallet) with a signed approveAgent action, and that wallet signs on the master’s behalf. The question moves from what can this key do to what can this signature authorise, and for how long.

On withdrawals, the precise position is this: Hyperliquid’s docs do not say whether an API wallet can sign withdrawals. The official SDK handles withdrawals and transfers with a different signing scheme from trading, and third-party integrations (e.g. NautilusTrader) state that these require the master key. Verify against your own setup before treating it as a security boundary.

Two documented rules bite in practice. API wallets only sign: querying account data with the agent’s address returns an empty result, which the docs call “a common pitfall”. And approving a new unnamed agent deregisters the previous unnamed one, so a second tool that sets up its own wallet can silently break the first. Agents are also pruned when they expire or when the account that registered them no longer has funds. See Hyperliquid API setup.

Alpaca: the finest scope, and an expiry you choose

Alpaca’s Custom level sets each API scope to Read & Write or Read only, so a key can edit watchlists while trading stays read-only. OAuth is separate: read-only is achieved by omitting trading and account:write from the requested scope, not by requesting a read-only scope.

Expiry is chosen at creation, so a key set to 90 days stops working on schedule. The secret is shown once and cannot be retrieved.

IBKR: the permission lives in the application

The TWS API has no credential. It is a socket to a logged-in TWS or IB Gateway, and the control is a setting in that application. IBKR’s wording: “The setting ‘Read-Only’ is enabled by default and will block all API orders. It must be unchecked to allow any orders from the API.”

IBKR is the only venue in this table where the default refuses orders. Users report error 321 with the text “The API interface is currently in Read-Only mode”; IBKR’s own table lists 321 only as a generic validation error. See IBKR TWS API setup.

What to do in code

Assert permissions at startup where you can. Binance exposes GET /sapi/v1/account/apiRestrictions, returning ipRestrict, createTime and every permission flag. A process that refuses to start when enableWithdrawals is true turns a silent exposure into a visible failure. Our fact cards record no equivalent endpoint for the other five venues, so store the intended configuration next to the credential and check it by hand.

Record expiry as data. Binance’s 90-day rule, OKX’s inactivity window, Alpaca’s chosen expiry and Hyperliquid’s valid_until all end a working setup without a code change. Alert before the date, not on it.

Treat permission refusals as permanent. -2015, 10005, 10010, OKX 50110 and an IBKR Read-Only rejection will not clear on retry. Fail loudly — see authentication errors across exchanges.

One credential per consumer. On Hyperliquid that means one named agent wallet per process, so approving another does not replace it.

Bound the funds. A sub-account with a limited balance caps the damage from software that is working as designed but wrong.

FAQ

Which exchanges require an IP whitelist to enable withdrawals?

Binance does: its docs state the IP Access Restriction filter must be applied before withdrawals can be enabled. On OKX, IP binding is recommended rather than required, and we did not find a withdrawal precondition. For Bybit and Alpaca the rule is not recorded in the sources we checked, so confirm it on the venue’s own key-management page.

Do exchange API keys expire?

Some do, for different reasons. Binance unchecks spot and margin trading 90 days after activation on keys without an IP whitelist. OKX expires unbound keys holding Trade or Withdraw after a period of inactivity. Alpaca keys expire on the date chosen at creation, and Hyperliquid agents can carry a custom expiry.

Can a Hyperliquid API wallet withdraw funds?

Hyperliquid’s docs do not say. The official SDK signs withdrawals and transfers with a different scheme from trading, and third-party integrations such as NautilusTrader state that these require the master key. Test it on your own setup before treating it as a security boundary.

Which venue blocks API trading by default?

IBKR. Its Read-Only API setting is enabled by default and blocks all API orders until you untick it. On the other venues here, a credential created with trading permission can trade as soon as it exists.