OKX vs Binance API: Passphrase, Signing, Demo Environments and Rate Limits Compared

OKX and Binance both have REST and WebSocket APIs, and ccxt supports both; both also have built-in grids, copy trading and a demo environment. Compared on whether a feature exists, the two look the same. What you actually change when writing a script is in the connection details: how many credentials there are, how a request is signed, how you switch to the demo environment, and what rate limits are counted against.

Sources: for OKX, the API v5 docs; for Binance, the Spot API docs. Binance's futures APIs have their own docs and are not covered here. This site mostly writes about OKX; what follows compares connection rules only and does not rate one exchange above the other.

OKX vs Binance API comparison table

Sources by row. OKX: API key creation, REST authentication, Demo Trading Services, Rate limits, WebSocket connect. Binance: Request security, Limits, Demo Mode, WebSocket API general information (the two WebSocket rows come from this page).

OKX has a Passphrase, Binance doesn't

OKX's docs say that creating an API key gives you three pieces of information: the APIKey and SecretKey are randomly generated by the platform, and the Passphrase is provided by you. The platform stores only an encrypted hash of the Passphrase, so a forgotten one cannot be recovered and you have to generate a new API key. Every private request carries it in the OK-ACCESS-PASSPHRASE header. Binance authenticates with an API key and a secret key (or an RSA or Ed25519 private key), and its docs have no Passphrase.

In ccxt this comes down to one field at initialization:

import ccxt

okx = ccxt.okx({
    'apiKey':   'YOUR_apiKey',
    'secret':   'YOUR_secret',
    'password': 'YOUR_Passphrase',   # OKX's third credential, called password in ccxt
})

binance = ccxt.binance({
    'apiKey': 'YOUR_apiKey',
    'secret': 'YOUR_secret',         # no third field
})

Moving from Binance to OKX, leaving this field out means authentication fails. password takes the Passphrase you set when creating the key, not your login password. Key creation is covered in the OKX API Quant Starter.

Switching to demo: a header on OKX, a different domain on Binance

This is where the two differ most, and where mistakes are easiest to make.

OKX: demo and live share one REST address, https://openapi.okx.com; the only difference is whether the request carries x-simulated-trading: 1. The URL tells you nothing about the environment, and a request without the header lands on live. With ccxt, call okx.set_sandbox_mode(True) and print okx.headers.get('x-simulated-trading') as a self-check; details are in How to Use OKX Demo Trading. WebSocket, by contrast, has separate wspap.okx.com addresses.

Binance: spot has two simulated environments, each with its own domain. Demo Mode's REST address is https://demo-api.binance.com/api; Spot Testnet is a different one. Binance's docs compare them this way: Testnet's prices and order books are independent from the live exchange and balances are reset every month; Demo Mode's prices and order books are similar to the live exchange and you can reset your balance whenever you want via the UI. The docs add: do not assume trading strategies that work in Demo Mode will work in the live exchange.

So on Binance, getting the address right gets the environment right; on OKX the address is always the same, and what you check is the header. Both need separately created keys for the simulated environment. When connecting ccxt to Binance's simulated environment, print binance.urls['api'] first to confirm whether it actually points at Testnet or Demo Mode.

What rate limits count: endpoint and account on OKX, IP and weight on Binance

OKX's rate limit section says each endpoint has its own limit, listed in the endpoint's details; public unauthenticated REST limits are based on IP address, private REST limits are based on User ID, and a sub-account has its own User ID; the limits for placing, amending and cancelling orders are independent of one another and are defined at the Instrument ID level. A rate-limited request returns error code 50011. On top of that, each sub-account is allowed at most 1000 order-related requests per 2 seconds, and exceeding it returns 50061.

Binance's Spot API docs put it this way: the limits are based on the IPs, not the API keys. Requests accumulate weight, and every response carries an X-MBX-USED-WEIGHT-(intervalNum)(intervalLetter) header showing how much that IP has used; the current limits are in the rateLimits array of /api/v3/exchangeInfo. Exceeding the limit returns HTTP 429, and failing to back off after a 429 gets the IP banned (HTTP 418), with bans scaling from 2 minutes to 3 days; the Retry-After header gives the number of seconds to wait.

What this means for a script: on Binance, several programs running from one IP share a single weight budget; on OKX, private endpoints are counted per account, and when the order rate on one instrument is not enough, the docs point to trading through multiple sub-accounts. OKX's per-endpoint figures and how to handle them are in OKX API rate limits.

What to change when moving a ccxt strategy between the two

• Initialization fields. Three on OKX, two on Binance, as above.
• How you switch to the simulated environment and check it. On OKX check the header; on Binance check the address.
• Instrument specs. Minimum order size and price and amount precision differ between the two; read them from limits and precision in what load_markets() returns rather than hard-coding them.
• Rate-limit and error handling. OKX's docs describe errors by error code (rate limiting is 50011), while Binance's describe them by HTTP status (429 and 418), so the retry branches have to be written separately for each. How OKX errors are grouped is in the OKX API error guide.
• Clock sync. OKX tolerates a 30-second difference; on Binance it is set by recvWindow, 5000 ms by default. With an inaccurate local clock, Binance is the one that errors first.

FAQ