Learn

Exchange APIs

Key permissions, testnet setup, IP whitelists, rate limits and the error codes you will actually hit, per exchange.

89 guides

• Alpaca API 403 Forbidden: what it means and how to find the cause

  Alpaca returns 403 for buying power, wash-trade protection, account restrictions, data plans and sometimes bad credentials. Read the code and message to tell which one you hit.

• Alpaca paper trading API

  Paper and live share one API specification and differ only by URL and credentials — which makes migration trivial and pointing at the wrong one equally trivial.

• Alpaca removed the PDT rule: what changed for API code

  The Pattern Day Trader rule is gone at Alpaca, and its account fields were removed on 2026-07-06. What changed, which fields your code must stop reading, and what to check instead.

• Alpaca vs IBKR API: REST keys vs the TWS socket

  Alpaca's Trading API and IBKR's TWS API compared for developers — transport, authentication, paper trading, rate limits, official SDKs and how errors reach your code.

• What to do if an exchange API key leaks

  Revoke first, investigate second — and know the venue-specific traps, including the one where revoking a key does not stop the signer.

• API key permissions compared across exchanges and brokers

  Permission scopes, withdrawal gating, IP binding, key expiry and sub-accounts on Binance, Bybit, OKX, Hyperliquid, Alpaca and IBKR, and what each one means for your code.

• Error handling patterns for trading APIs

  Classify before you react. Most trading integration bugs come from treating a refusal and an unknown outcome as the same kind of failure.

• API signature methods compared: HMAC, RSA, Ed25519 and EIP-712

  How Binance, Bybit, OKX and Hyperliquid build the string they sign, which key types and encodings each accepts, and why a signer ported between venues gets rejected.

• Surviving exchange API changes

  Endpoints get deprecated, fields get added, and libraries rewrite themselves. What breaks silently, and how to find out before your positions do.

• Authentication errors across exchanges: a code-by-code map

  Got -2015, 10003, 50113, "User or API Wallet does not exist", a 403 or IBKR 502? What each auth error means on six venues, how to classify it, and which page has the fix.

• Backfilling trade and price history

  Pagination, archive endpoints and retention limits. The three things that make historical data harder to collect correctly than it looks.

• Disabling withdrawals on a Binance API key

  You do not disable withdrawals on Binance — you decline to meet the precondition for enabling them. Why that is a stronger guarantee than a checkbox.

• Binance API error -1013: Filter failure, and how to fix each one

  Error -1013 is a generic rejection; the real cause is the 'Filter failure' text in msg. Each filter mapped to the field to fix, and why futures never shows this message.

• Binance API error -1022: signature for this request is not valid

  Error -1022 means the bytes Binance verified differ from the bytes you signed. The exact payload rule, the mismatches behind most failures, and a byte-level check.

• Binance API error -1021: timestamp outside recvWindow

  Error -1021 comes with two messages that need opposite fixes, a request that arrived too late or one stamped ahead of Binance's clock. How to tell which, and fix it.

• Binance API error -1102: mandatory parameter empty or malformed

  Error -1102 names the parameter Binance could not use. Why a value you did send can still count as missing, from empty strings and nulls to bad number formats and mode changes.

• Binance API error -1121: Invalid symbol, and finding the mismatch

  Error -1121 means the API you called does not recognise that symbol string. The usual mismatches (format, product, environment) and a one-call check that settles it.

• Binance API error -2010: NEW_ORDER_REJECTED and what msg says

  Error -2010 only says the order was rejected; the reason is in msg. Insufficient balance, duplicate client order ID, closed market and more, with what to do for each.

• Binance API error -2011: CANCEL_REJECTED, Unknown order sent

  Error -2011 on a cancel usually means Binance cannot find that order open, and often it already filled. Why that matters, the other causes, and how to reconcile first.

• Binance API error -2015, and how to tell which cause you have

  Diagnose Binance -2015 by checking environment, source IP and current permissions, without assuming validation order or treating a failed query as proof of revocation.

• Binance API error -2014: API-key format invalid

  Error -2014 means the value in X-MBX-APIKEY is not shaped like a key. Binance documents no causes, so here are the likely ones, how to check each, and how to stop it recurring.

• Binance API IP whitelist and the 90-day expiry

  Without an IP whitelist, a Binance key's spot trading permission switches itself off after 90 days. Why that happens, and how to find the address to whitelist.

• Binance API key permissions

  What each permission flag on a Binance key actually controls, how to read a key's real state over the API, and the two rules that make the model different from other venues.

• Binance API rate limits and error -1003

  Binance meters request weight, not request count — so "how many calls per minute" is the wrong question. What -1003 means and how 418 differs from 429.

• Binance futures error -2019: MARGIN_NOT_SUFFICIEN, margin insufficient

  Error -2019 means a USDⓈ-M order needs more margin than is available to it. Where the shortfall comes from, how -2027 and -2028 differ, and what to check first.

• Binance futures error -4164: order's notional must be no smaller

  Error -4164 rejects USDⓈ-M orders below the symbol's minimum notional, unless they are reduce-only. Where the threshold lives, why it bites on exits, and how to fix it.

• Binance testnet API keys

  Testnet is a separate host with separate credentials, which makes environment mistakes fail loudly. What transfers to production and what quietly does not.

• Binance vs Bybit API: signing, limits and test environments

  A head-to-head of the Binance and Bybit APIs for developers — signature payloads, key types, timestamp windows, rate-limit models, testnets and error codes.

• Binance vs OKX API: passphrase, timestamps, demo mode and errors

  How the Binance and OKX APIs differ where it costs integration time — the OKX passphrase, ISO timestamps, header-switched demo trading, position parameters and error codes.

• Bybit API error 10003 — invalid key or too many sessions

  Over REST, Bybit's 10003 means your key does not match the host's environment; on WebSocket order entry, too many sessions. How to tell which you have.

• Bybit API error 10004: fixing an invalid signature

  Bybit's 10004 means the X-BAPI-SIGN it recomputed did not match yours. The exact string to sign, the encoding per key type, and how to find where signed and sent diverge.

• Bybit API error 10002: request time outside recv_window

  Bybit accepts a timestamp up to recv_window behind its clock but under one second ahead. How to measure your offset and tell a fast clock from a stale request.

• Bybit API errors 10006 vs 10018: account vs IP rate limits

  Bybit has two rate-limit layers. 10006 is per account and per endpoint; 10018 is per IP. How to tell which you hit, what each one implies, and how to pace against both.

• Bybit API error 10010: unmatched IP on a bound API key

  Bybit's 10010 means the request came from an IP not bound to the API key. How to find the address Bybit actually sees, and why it breaks after deploys, restarts and containers.

• Bybit API error 110007: available balance is insufficient

  Bybit's 110007 means the order needs more available balance than the account has free. What eats into available balance, how to size from it, and how to handle the error in code.

• Bybit API error 10005: permission denied on an API key

  Bybit's 10005 means the key was accepted but lacks the permission this endpoint needs. How to find which key and permission, and why editing the key often seems not to help.

• Bybit API error 110028: open orders block a position mode switch

  Bybit's 110028 means the symbol still has open orders, so one-way and hedge mode cannot be swapped. How to clear them, switch cleanly, and update positionIdx afterwards.

• Bybit API error 110043: set leverage has not been modified

  Bybit's 110043 usually means you asked for the leverage already set. Why that is normally a no-op, when it is not, and how to handle it in code without masking real failures.

• Bybit API key setup and request signing

  Bybit V5 uses four headers and a pre-hash string that does not match Binance or OKX. The construction, the common signing failures, and how to tell them apart.

• Bybit testnet setup

  A separate hostname and separate credentials, so environment mistakes fail loudly. What carries over to mainnet, and why a mismatched key returns 10003.

• Bybit vs OKX API: auth, account modes and liquidation scope

  Bybit and OKX APIs compared for developers — signing and the passphrase, timestamp rules, demo environments, rate limits, and how account modes set liquidation scope.

• CCXT's common errors, and what they mean

  The exception hierarchy splits into "the exchange refused you" and "the outcome is unknown". Which branch an error lands in decides whether retrying is safe.

• Getting started with CCXT

  One interface across many exchanges, with a unified error hierarchy that is the real reason to use it — and the venue differences it cannot hide from you.

• CCXT vs native exchange SDKs: what the abstraction hides

  CCXT or each exchange's own SDK? What CCXT unifies — signing, method names, an error hierarchy — and what it cannot hide: account modes, position parameters and native codes.

• Choosing an exchange for automation

  The API properties that decide how much work an integration is — and they are not the ones exchanges advertise.

• Clock sync and timestamp errors

  Signed requests carry a timestamp inside a narrow window. Drift produces authentication failures that look exactly like signing bugs, and the fix is not in your code.

• Exchange API key security checklist

  The controls that hold when your software is wrong, across five venues — including the one with no API keys and the one that ships safe by default.

• Exchange outages and degraded mode

  Venues go down, and they go down badly more often than they go down cleanly. What your automation should do when it cannot tell what is true.

• Hyperliquid API setup and agent wallets

  There is no API key. A master account approves a wallet to sign for it — which changes what permissions mean and why a new account runs out of requests.

• Hyperliquid 'Order must have minimum value' error, and what's next

  Why Hyperliquid rejects small orders inside an HTTP 200 response, how rounding and partial closes cause it, and the tick-size and reduce-only errors you will hit next.

• Hyperliquid 'User or API Wallet does not exist': causes and fixes

  Hyperliquid recovered a signer it does not recognise. How to tell a broken signature from an expired or replaced agent wallet by reading the address in the error.

• Hyperliquid vs Binance API: agent wallets, EIP-712 and nonces

  How Hyperliquid's API differs from Binance for developers — agent wallets instead of API keys, EIP-712 vs HMAC, nonces vs recvWindow, string errors and withdrawals.

• IBKR error 326: client id is already in use — how to fix it

  Error 326 means another connection to the same TWS session already holds your client ID. How ghost sessions and reconnect races cause it, and how to assign IDs so it stops.

• IBKR error 502 "Couldn't connect to TWS": causes and fixes

  Error 502 means the socket to TWS or IB Gateway never opened. Why TWS logs show nothing, and a four-step check covering settings, ports, paper vs live and Trusted IPs.

• IBKR market data errors 354, 10089, 10090, 10186 explained

  IBKR market data codes mean different things — no subscription, no API entitlement, a partial one, or delayed fallback. Tell them apart and apply the right fix.

• IBKR TWS API setup

  Two defaults decide whether the TWS API works at all — socket clients are off, and Read-Only API is on. Ports, connection, and the constraints you cannot engineer around.

• Monitoring a trading integration

  The failures that cost money are the silent ones — a stale stream, an expired permission, a position that drifted. What to alert on and what to ignore.

• OKX API error 50011 "Rate limit reached": what is being counted

  OKX returns 50011 with HTTP 200 or 429. How its limits are counted per IP, user ID and instrument, why REST and WebSocket share order limits, and how to stay under them.

• OKX API error 50102 "Timestamp request expired" and how to fix it

  OKX rejects signed requests more than 30 seconds off its clock. Why a timezone offset is the usual cause, how 50102 differs from 50112, and a one-request check.

• OKX API error 50111 "Invalid OK-ACCESS-KEY" and its neighbours

  50111 means OKX does not recognise the API key you sent. A table of OKX's authentication codes, 50101 to 50115, so you can tell which credential problem you have.

• OKX API error 51000 "Parameter error" and the posSide trap

  51000 is OKX's catch-all for a bad request parameter, and the message names the field. How to read it, the documented posSide case in long/short mode, and what to check next.

• OKX API error 51008: decoding the sub-code (51008_1000 and more)

  51008 means an order could not be funded, and the sub-code after the underscore says why. How to read 51008_1000, _1001, the auto-borrow variants, and your account mode.

• OKX API passphrase and the four-header model

  OKX needs a fourth credential that Binance and Bybit do not have, and switches REST to demo trading with a header rather than a hostname. Both surprise people.

• OKX API error 50113 "Invalid Sign"

  The signature you computed does not match OKX's. Five causes in order of likelihood, including the one that makes some endpoints work and others fail.

• Order lifecycle and partial fills

  An order is not filled or unfilled. It moves through states, and the partially-filled one breaks more automation than any other single case.

• Order types explained

  Market, limit, stop, stop-limit and the flags that modify them. What each guarantees, what it does not, and which guarantee you are giving up.

• Position reconciliation

  The single check that catches the failures nothing else reports. What to compare, how often, and what to do when the numbers disagree.

• Read-only vs trade permission on an API key

  Every venue implements the read/trade split differently — and on one of them the safe setting is the default. A comparison across five venues and what it implies.

• Rate limit models compared: weight, count, IP, UID and instrument

  What Binance, Bybit, OKX, Hyperliquid, Alpaca and IBKR actually meter, which headers report your usage, and what 429, 418 and 403 mean on each. Mechanism only, no quotas.

• Retrying a failed order is not safe

  A timeout on an order means the outcome is unknown, not that it failed. And a client order ID does not make the retry idempotent the way most advice claims.

• Secrets management for trading automation

  Where exchange credentials actually leak — logs, shell history, synced dotfiles, MCP config files — and how to make a leak cost less when it happens.

• Using sub-accounts for automation

  A funding boundary bounds damage from correct-but-wrong behaviour, which no permission flag does. The strongest control available for third-party code.

• Symbol filters and minimum order sizes

  Your order is rejected before it reaches the matching engine because it failed a per-symbol filter. What the filters are and why they break sizing logic.

• Testnet, demo and paper environments compared across venues

  REST and WebSocket hosts, key issuance and live-key compatibility for the practice environments of Binance, Bybit, OKX, Hyperliquid, Alpaca and IBKR, with the traps in each.

• Timestamp tolerance compared across exchange APIs

  Binance recvWindow, Bybit's receive window, OKX's 30-second rule and Hyperliquid nonces side by side, with the ahead-of-server rule and the error code each venue returns.

• WebSocket reconnection patterns

  A stream that reconnects silently leaves your state wrong with no error. Reconnection is not the hard part — reconciling what you missed is.

• WebSocket vs REST for trading

  Streams are for knowing, requests are for doing — and the mistake that matters is polling for data you should stream, which spends the budget you need to exit.

• What is a client order ID?

  A client order ID is the name you give an order before the exchange assigns one. What it is unique against, how to query by it, and why it is not an idempotency key.

• What is a post-only order?

  A post-only order rests on the book as a maker or is refused. What the refusal looks like, why it spikes in fast markets, and how to handle it without chasing price.

• What is a reduce-only order?

  A reduce-only order can shrink a position but never open or flip one. How venues enforce it, when a resting one gets cancelled, and why every exit should carry it.

• What is an agent wallet? Hyperliquid's API wallets explained

  An agent wallet is a key a master account approves to sign for it. How approval, named slots, nonces and expiry work, how it differs from an API key, and where to draw the line.

• What is HMAC request signing in exchange APIs?

  HMAC signing proves a request came from your key without sending the secret. How exchanges build the signed string, where Binance, Bybit and OKX differ, and why it fails.

• What is lot size? Quantity step, minimums and contract units

  Lot size is the quantity grid a venue enforces per symbol. LOT_SIZE vs MARKET_LOT_SIZE, minimum quantity vs minimum notional, contracts vs coins, and safe rounding code.

• What is paper trading? How simulated fills flatter your results

  Paper trading sends orders to a simulated account. How paper engines decide fills, how that differs from testnet and backtests, and how to adjust results before trusting them.

• What is recvWindow? Binance's request time window explained

  recvWindow sets how late a signed Binance request may arrive, not how early. What it can and cannot fix, the two -1021 messages, and how Bybit's recv_window compares.

• What is request weight in the Binance API?

  Request weight is Binance's per-call cost, metered per IP, while orders are counted per account. How the headers expose both and how to build a limiter around them.

• What is time in force? GTC, IOC, FOK and GTD explained

  Time in force decides what happens to the unfilled part of an order. What GTC, IOC, FOK and GTD each do, how post-only fits in, and which to choose when automating.

• What is tick size? Price increments and rounding in trading APIs

  Tick size is the smallest price step a venue accepts. How Binance and Hyperliquid reject off-tick prices, which way to round each order type, and why floats fail.

• What is a Unified Trading Account (UTA) on Bybit?

  Bybit's Unified Trading Account sets margin mode for the whole account, not per symbol. How liquidation scope, error codes and OKX's account modes differ.