An exchange API key is a pair of API Key and API Secret. With this key, programs and services work with an account through the API: they read balances, open and close trades, and perform other operations allowed for that key without logging in to the web dashboard.
Goal of the material: to describe the restrictions that an exchange applies to API requests: signature verification through API Secret, key permissions, binding the request source to an IP whitelist, withdrawal limits through a withdrawal address whitelist, and balance isolation through sub-accounts. These restrictions reduce the risk that a leak of the API Key + API Secret pair will lead to asset withdrawal or loss-making trades.
🧭 How crypto exchanges control API access
API keys are used by trading bots, terminals, reporting services, and internal integrations. An exchange executes an API request only after checking the signature (API Secret), the operation rights (permissions), the source IP address (IP whitelist), and the request time (timestamp and recvWindow). The time check blocks a replay of the request later, even if the request has been intercepted.
API risk is reduced through key settings. IP whitelist accepts requests only from specified IP addresses. Permissions limit the set of operations that the exchange will execute with the key. A withdrawal address whitelist limits the list of recipients. Sub-accounts separate balances and keys between sub-accounts so that one key does not have access to all account assets.
🔍 How an exchange verifies an API request: signature, rights, IP, and time
An API key consists of an API Key (the key identifier) and an API Secret (the secret used for signing). The signature confirms to the exchange that the request was created using the API Secret and was not changed in transit.
- Creating request parameters for the exchange API endpoint (the API address that accepts a specific operation)
- The request defines the operation: open or cancel an order, get a balance, perform a transfer, or initiate a withdrawal.
- The request contains a timestamp and sometimes an allowed time window (recvWindow). The exchange compares these values with its own time and rejects the request if it falls outside the allowed interval.
- Signing request parameters through HMAC
- HMAC is a hash-based signature generated with a secret key. The parameter string is signed with the API Secret.
- The exchange recalculates the HMAC using the same parameters and compares the signature. A mismatch means that the sender does not own the API Secret or that the parameters were changed.
- Checking key restrictions and deciding whether to execute
- Permissions define which operations are allowed for the key (read/trade/transfer/withdraw on most centralized exchanges, CEXs).
- IP whitelist restricts request sources. The exchange rejects a request if the sender’s IP is not included in the key’s whitelist.
- Executing the operation and returning the result
- If rights are insufficient, the exchange returns a rejection and does not execute the operation, even with a valid signature.
- If the IP does not match, the exchange returns a rejection at the authorization stage and does not proceed to a trading or withdrawal operation.
API access components controlled by the exchange
The exchange reduces API risk through three checks in each request: signature through API Secret, permissions for operations, and IP whitelist for the request source.
- API Secret is stored only in a secrets vault and in the memory of the process that signs requests.
- Permissions are enabled for the key’s task: reading for reporting, trading for a bot, and withdrawal only for operational payouts.
- IP whitelist contains only the IP addresses of servers that actually send requests, so the list does not expand the attack surface.
If an attacker obtains an API Key without the API Secret, the exchange rejects the request because the signature is invalid. If an attacker obtains both the API Key and API Secret, the exchange rejects the request when permissions do not allow the operation or the IP is not included in the whitelist.
🎯 What losses are possible through API: withdrawals, transfers, and trading losses
API damage depends on the enabled permissions and on the balance available to that key. A trade-only key carries lower risk on a sub-account with a small working balance and higher risk on a sub-account with core capital.
Three scenarios that an exchange executes through API
API losses occur through withdrawal, internal transfer, or trades that create a loss at the execution price.
- Direct withdrawal: a key with withdraw permission initiates a withdrawal to an address that the exchange allows after its checks and whitelist rules.
- Internal transfer: a key with transfer permission moves assets between product wallets or between sub-accounts if the exchange allows such operations through the API.
- Trading loss without withdrawal: a key with trade permission places orders on a low-liquidity pair and executes trades at a worse price, creating a loss from slippage, spread, and fees.
Disabled withdraw permission removes direct withdrawal. Trade permission remains a source of loss if a large balance is stored in the trading wallet and the key is not restricted by IP and instruments.
Signals after which an API check becomes necessary
- Orders appeared that do not match the trading system logic and launch schedule.
- Transfers appeared between wallets or sub-accounts without an operational reason.
- New permissions appeared in the key settings or IP whitelist was removed.
- Signature errors appeared in the trading system logs and request frequency increased while the code remained unchanged.
🌐 IP whitelist: binding a key to the server that sends requests
IP whitelist forces the exchange to accept requests only from pre-specified IP addresses. If the API Secret enters code, logs, backups, or a third-party service, an attacker will not be able to send a request from an IP that is not in the whitelist.
Choosing a stable source for API requests
- A VPS (virtual private server) with a static public IP is suitable for IP whitelist and for continuous trading system operation.
- Home internet with a dynamic IP is not suitable because an IP change causes API request failures until the whitelist is updated.
Configuring IP whitelist for an API key
- IP whitelist includes the IP of the trading system server and the backup server if the backup server is actually used.
- If the exchange supports CIDR (subnet notation, for example 203.0.113.10/32), the smallest range is set so that the list of sources is not expanded.
Checking API access resilience
- A backup API key on a separate IP is used during infrastructure migration and server address changes.
- The procedure for updating IP whitelist is documented in advance so that an IP change does not coincide with loss of order control.
In cloud infrastructure, requests may go out to the internet through NAT (address translation at the network edge). In this case, the external IP visible to the exchange may differ from the IP of the container or virtual machine. The IP whitelist should contain the egress IP (the external IP of outgoing traffic), otherwise the exchange will reject requests.
IP whitelist does not protect against VPS compromise. If the server is taken over, an attacker will send requests from the same IP, so VPS access protection and update control remain part of API protection.
IP whitelist blocks requests from unauthorized servers because the exchange compares the source IP with the whitelist and rejects the request before executing a trading or withdrawal operation.
🔑 Permissions: which rights are assigned to a key for a specific task
Permissions define which API endpoints the exchange will allow this key to call. The names of rights depend on the exchange, but the model is usually similar: read for reading, trade for orders, transfer for internal transfers, and withdraw for blockchain withdrawals.
| Task | Allow | Block | Blocked operation |
|---|---|---|---|
| Screener/analytics | Read | Trade; Transfer; Withdraw | Placing orders and moving assets |
| Trading bot | Read; Trade | Withdraw | Direct withdrawal of funds through API |
| Reporting | Read | Trade; Transfer; Withdraw | Operations if the reporting service is compromised |
| Operational transfers | Read; Transfer | Trade; Withdraw | Trading operations and blockchain withdrawals |
Read-only key for monitoring and reporting
A read-only key is used when a system needs to read balances, trade history, and position statuses but must not change the account state.
- A read-only key blocks placing and canceling orders because the exchange rejects trading endpoints for this key.
- IP whitelist limits data access to a specific server and blocks requests from unauthorized IPs if the API Secret leaks.
- A separate read-only key for reporting isolates the reporting service risk from the trading key risk.
A read-only key exposes balances and history but does not allow withdrawals or trades because the exchange rejects trade/transfer/withdraw endpoints.
Trade key for a trading system without withdrawals
A trade key is used to place and cancel orders. Withdraw permission is not needed for trading operations.
- Trade permission gives access to order and position management within the account’s markets.
- Disabled withdraw permission blocks withdrawals because the exchange rejects withdrawal endpoints for this key.
- IP whitelist binds the key to the trading system server and blocks requests from unauthorized machines if the API Secret leaks.
A trade-only key creates risk for funds in the trading wallet, so the trading sub-account usually holds a working balance, not core capital.
Transfer key for internal movements
A transfer key is used for transfers inside the exchange: between product wallets or between sub-accounts if the exchange allows such operations through the API.
- Transfer permission allows internal transfers that do not go to the blockchain.
- Disabled trade permission excludes trades because the transfer key cannot create orders.
- Disabled withdraw permission excludes blockchain withdrawals if the transfer key is compromised.
Separating transfer and trade into different keys reduces damage from a leak because one key does not provide access to both trades and asset movement.
Permissions define which operation the exchange will allow for this key. Extra permissions expand the set of actions that the exchange will execute with a compromised key, so rights are enabled only for a specific process.
🏷️ Withdrawal protection: address whitelist, confirmations, and limits
Withdraw permission allows an API key to initiate withdrawal of funds from an exchange balance to a blockchain. Withdrawal protection relies on a recipient address whitelist, control over whitelist changes, and withdrawal limits.
In trading integrations, withdraw permission is usually disabled. Orders, cancellations, and balance reads are executed inside the exchange and do not require network withdrawals. Read permission is enough for monitoring and reporting. Trade permission is enough for algorithmic trading.
Example: a trading bot works through a key with trade permission and without withdraw permission. If the key is compromised, an attacker will be able to open and close trades through trading endpoints. The exchange will reject a withdrawal request because the key does not have withdraw permission.
A withdrawal address whitelist limits the withdrawal recipient: the exchange sends funds only to pre-added addresses. On many exchanges, adding an address to the whitelist requires 2FA (two-factor authentication) and confirmation through a separate channel, such as email, an app, or a hardware key. In this case, withdrawal to a new address depends not only on the API key but also on control over these confirmation channels.
A whitelist change delay (security lock or hold) does not activate the added address immediately. When the delay is enabled, withdrawal to a new address is blocked for the hold period, so the added address can be noticed before the first withdrawal.
API connectivity for trading bots, trade-only keys, and IP whitelist are covered in the material “Earning with Crypto Trading Bots”.
Withdrawal limits restrict the amount of losses if an attacker obtains a key that passes whitelist and confirmation checks. The daily limit is set for regular operational payout amounts, not for the total account balance, so that one withdrawal cycle cannot drain the entire deposit.
Email compromise increases risk because many exchanges use email for confirmations of address additions and security resets, including confirmation links and notifications about whitelist changes.
Withdraw permission without a withdrawal address whitelist makes an API key leak a direct channel for blockchain withdrawal. Withdraw permission with a withdrawal address whitelist and a delay on whitelist changes shifts the critical risk to compromise of confirmation channels. Withdrawal limits restrict the loss amount if the other restrictions are bypassed.
🛡️ Sub-accounts: isolating balances, keys, and processes
Sub-accounts separate balances and API keys inside one exchange. If a key leaks, operations are limited to the assets of a specific sub-account.
- Separating storage and trading across different sub-accounts
- The storage sub-account holds core capital and does not use persistent trading API keys.
- Trading sub-accounts hold working balances for specific bots and strategies.
- Controlling internal transfers through API
- Disabling transfer permission on trading keys reduces the ability to move assets if a trading key leaks.
- A dedicated transfer key is used when internal transfers are part of the operational process.
- Restricting key instruments when trading pair whitelist is supported
- Trading pair whitelist blocks trades in instruments that do not belong to the trading system.
- Pair restrictions reduce the risk of losses on low-liquidity markets.
Isolation model for multiple trading systems
The isolation model separates balances through sub-accounts and separates access through API keys, permissions, and IP whitelist.
- One trading system on one exchange works through a separate sub-account and a trade-only key bound to the VPS IP.
- Reporting is connected with a read-only key on a separate server so that a reporting leak does not expose the trading key.
- Operational transfers are performed with a transfer key without trade and withdraw permissions.
If a trading system key leaks, the exchange executes operations only within the balance of its sub-account, so losses are limited to the working balance.
🗄️ Secret storage and rotation: how API Secret leaks from infrastructure
API Secret more often leaks not through the exchange but from trading system infrastructure: code repositories, CI/CD pipelines (automated build and deployment processes), application logs, database dumps, screenshots, and backups. Secret management defines where the API Secret is stored and which roles can access it.
API Secret is not stored in application code. The secret value is injected when the service starts from protected storage and is not saved in project files or the repository. Code and configuration keep a reference to the secret, not its value.
Example: a trading bot is deployed through CI/CD. Only the secret name is stored in the repository, and the API Secret value is injected at the deployment stage from protected storage. If the code and commit history leak, the API Secret is absent from them.
In production, API Secret is stored in a secret manager — a service that keeps secrets encrypted and gives them only to processes with permission through IAM (role-based access management). This model separates production secrets from development environments and test services.
Behavioral causes of mistakes in risk management and trading plans are covered in the material “Trading Psychology”.
API key rotation reduces the risk of a long-lived leak. Rotation includes creating a new key on the exchange, switching the system to the new API Secret, and revoking the old key so that the exchange stops accepting signatures with the old secret.
The switch is planned for a period without open positions and active limit orders so that changing the API Secret does not interrupt order and risk management.
Minimum rules for storing API Secret
- API Secret is stored in a secret manager or encrypted storage with access control.
- API Secret does not enter Git, Docker image, CI artifacts, or backups in plain text.
- The production secret is not accessible from the development environment and is not accessible to roles that do not run the trading system.
- Rotation includes revoking the old key after switching so that the old secret stops working on the exchange side.
Permissions, IP whitelist, and withdrawal address whitelist protect on the exchange side, while secret management reduces the risk of API Secret leakage from code and logs on the infrastructure side.
🧩 Third-party terminals and bots: how connection affects risk
A third-party service receives the API Key and API Secret to sign requests on behalf of the account. If the service accepts the key in a web dashboard, the API Secret is stored in the provider’s infrastructure. During a provider incident, an attacker may be able to sign requests and pass signature verification on the exchange side.
✅ Signs of controlled risk
- The service works with read-only and trade-only keys and does not require withdraw permission for trading and reporting.
- The service shows an API action log: created orders and called endpoints.
- The service supports connection through a separate sub-account with a limited working balance.
❌ Signs of elevated risk
- The service requires withdraw permission for features that are not related to operational payouts.
- The service requires disabling IP whitelist and does not offer a model with a user-side agent and a fixed IP.
- The service does not provide API action history, so investigation relies on indirect signals.
Configuration example: signals and reporting use a read-only key, trading operations use a trade-only key on a sub-account with a working balance, and API withdrawals are disabled.
A third-party service does not cancel exchange restrictions. A sub-account, IP whitelist, minimal permissions, and disabled withdraw permission limit risk to the working balance.
🧯 Response to a key leak: stopping execution and preserving traces
When a leak of the API Key + API Secret pair is suspected, risk develops quickly because the exchange executes operations immediately after checking signature, rights, IP, and request time. Response begins with stopping authorization for the key and preserving operation traces.
- Revoking the key on the exchange side
- Disabling or deleting the key stops acceptance of signed requests for this API Key.
- Disabling all sub-account keys is used if the source of the leak is not identified.
- Preserving operation traces
- The list of open orders and trade history for the anomaly period show which operations were executed.
- Withdrawal history and withdrawal address whitelist changes show withdrawal attempts and address preparation.
- Closing additional account access channels
- Password change and 2FA check reduce the risk of web interface access.
- Email security checks are needed because withdrawal confirmations and whitelist changes are often tied to email.
- Restoring working access
- A new key is created with minimal permissions and IP whitelist for the current server.
- API Secret is updated in the secret manager so that the old secret stops being used.
Key revocation stops execution of actions because the exchange stops accepting signatures for this API Key, even if requests continue to arrive.
✅ Configuration that reduces withdrawal risk after a key leak
Withdrawal risk after a leak of the API Key + API Secret pair is reduced when the trade key does not have withdraw permission, requests are restricted by IP whitelist, and core capital is separated from the trading sub-account.
Minimum parameter set for a trading system trade key
- The trading system runs on a VPS with a fixed IP, and this IP is added to the key’s IP whitelist.
- The key has read + trade permissions and does not have withdraw permission.
- The trading sub-account contains the working balance, while core capital is stored separately without persistent trading keys.
- API Secret is stored in a secret manager or encrypted storage and does not enter repositories or logs.
IP whitelist, minimal permissions, withdrawal address whitelist for rare withdrawals, and isolation through sub-accounts limit damage to the working balance and reduce the risk of blockchain withdrawal through a compromised key.
❓ FAQ on API key security
Why does IP whitelist protect even if API Secret leaks?
The exchange compares the request source IP with the key’s IP whitelist and rejects the request if the IP does not match. The HMAC signature may be valid, but the operation will not be executed because the IP check happens on the exchange side.
When is withdraw permission actually needed?
Withdraw permission is needed for automated operational payouts to the blockchain. For trading, monitoring, and reporting, withdraw permission is not needed because these processes use trading and read endpoints inside the exchange.
Why can a trade-only key cause losses without withdrawal?
A trade-only key allows placing orders. With access to a trade-only key, an attacker can execute trades at a worse price on a low-liquidity pair and create losses from slippage, spread, and fees when a large balance is stored in the trading wallet.
Why use a separate sub-account for each trading system?
A sub-account limits the balance available to the key. If a trading system key leaks, damage is limited to the assets of this sub-account because the exchange executes operations within the balance of the specific sub-account.
How can keys be rotated without losing order control?
Rotation includes creating a new key, switching the trading system to the new API Secret, and revoking the old key. The switch is planned for a period without open positions and active limit orders so that the key change does not interrupt order management.
How is the risk of connecting a third-party terminal limited?
Risk is limited by a trade-only key on a sub-account with a working balance, IP whitelist (if requests go through a user-side agent), and disabled withdraw permission when the terminal does not participate in operational withdrawals.
🧷 How API restrictions reduce withdrawal and trading damage risk
API risk depends on allowed operations and on the checks that the exchange applies to each request: signature (API Secret), permissions, IP whitelist, and request time parameters.
- Disabled withdraw permission blocks blockchain withdrawals through API because the exchange rejects withdrawal endpoints for a key without this right.
- A withdrawal address whitelist limits the recipient because the exchange sends funds only to pre-added addresses.
- IP whitelist limits the request source because the exchange rejects requests from IPs that are not in the key’s list, even with a valid signature.
- Sub-accounts limit the amount of losses because the key gets access to the balance of a specific sub-account, not to all account assets.