Binance vs OKX API: passphrase, timestamps, demo mode and errors
Figures on this page are as of 2026-09. Fees, limits and margin tiers change — check the venue's own docs.
Binance and OKX both sign requests with HMAC-SHA256 and both publish long lists of numeric error codes, so a Binance integration looks like a head start on OKX. It is less of one than it looks. OKX adds a third credential, uses a different timestamp format with a much wider tolerance, switches demo trading with a header instead of a hostname, and names its position parameters differently.
This comparison is for developers moving code between the two or planning to support both. It covers mechanism only and does not recommend either venue. For a broader checklist, see choosing an exchange for automation.
Short answer
- You want test and production separated by hostname → Binance. OKX demo
REST uses the production host plus the
x-simulated-trading: 1header (its demo WebSocket does have its own host). - Your servers’ clocks are loosely managed → OKX’s documented tolerance is 30 seconds either way; Binance defaults to a 5000 ms window and rejects anything more than one second ahead.
- You want an unrestricted-IP key never to be able to withdraw → Binance documents that rule. OKX makes IP binding strongly recommended but not required.
- You need to rate-limit per instrument rather than per IP → OKX’s trading limits are defined per instrument ID; Binance meters weight per IP.
What they have in common
- HMAC-SHA256 signatures, with a server time endpoint to sync against.
- Scoped keys, with withdrawal as a separate permission and IP restriction available.
- One-way and hedge position modes on perpetuals, with a required side parameter in hedge mode.
- Numeric error codes in a JSON body, plus a demo environment that needs its own keys.
Where they actually differ
Credentials and the signed string
| Binance | OKX | |
|---|---|---|
| Credentials | Key + secret | Key + secret + passphrase |
| Key header | X-MBX-APIKEY | OK-ACCESS-KEY |
| Other headers | — (timestamp and signature are parameters) | OK-ACCESS-SIGN, OK-ACCESS-TIMESTAMP, OK-ACCESS-PASSPHRASE |
| Signed string | Query string concatenated with the body | timestamp + method + requestPath + body |
| Output | Hex | Base64 |
| Algorithm | HMAC; Spot also documents RSA and Ed25519 keys | HMAC-SHA256 |
On OKX the method must be uppercase, and for GET the query string is part of
requestPath, not the body. The timestamp in the signed string must be the
same value as the header. On Binance, non-ASCII characters must be
percent-encoded before signing.
The passphrase is the part people miss. It is set when you create the key,
OKX stores only a salted hash of it, and a lost passphrase means creating a new
key. OKX has dedicated codes for it — 50104 when the header is empty, 50105
when it is wrong. See the OKX API passphrase and,
for the general mechanism, what HMAC request signing is.
Timestamp format and tolerance
| Binance | OKX | |
|---|---|---|
| Format | Unix milliseconds (Spot also accepts µs) | ISO 8601 UTC with ms, e.g. 2020-12-08T09:08:57.715Z |
| Rule | Rejected if more than 1000 ms ahead, or older than recvWindow | Rejected if it differs from server time by more than 30 seconds |
| Window | recvWindow, default 5000 ms; Spot max 60000 ms | Fixed |
| Error | -1021 | 50102 “Timestamp request expired.”; 50112 for a malformed value |
OKX says local timezone offset is “the most common cause” of 50102 — an ISO
string built from local time instead of UTC. WebSocket login on OKX uses Unix
epoch seconds, not ISO 8601, so the two OKX transports need different
timestamp code. See clock sync and timestamps
and timestamp tolerance compared.
Permissions and IP rules
OKX keys carry any combination of Read, Trade and Withdraw. IP
binding is strongly recommended, not required. Keys without it that hold trade
or withdraw permission expire after a period of inactivity (the window is on
OKX’s key-creation page); demo keys are exempt. Relevant codes: 50110 (IP not
whitelisted), 50120 (key lacks permission).
Binance ties permissions to IP restriction more tightly: withdrawals cannot be
enabled without it, and a key with no whitelisted IP loses Spot & Margin trading
permission 90 days after activation. GET /sapi/v1/account/apiRestrictions
reports a key’s permissions; the OKX sources we checked do not cover an
equivalent endpoint, so we make no claim about one. See
Binance API key permissions and
API key permissions compared.
Rate-limit models
Binance meters request weight per IP (X-MBX-USED-WEIGHT-*) and order
counts per account (X-MBX-ORDER-COUNT-*). 429 means slow down; continuing
earns a 418 IP ban, both with Retry-After.
OKX sets limits per endpoint, and the basis varies: public REST per IP,
private REST per User ID (sub-accounts have their own), WebSocket
login/subscription per connection. Trading endpoints — place, amend, cancel —
are limited per instrument ID, shared across REST and WebSocket, with batch
and single-order endpoints counted separately. A separate sub-account order
limit runs in parallel (50061). Exceeding a limit returns 50011, which the
docs list with both HTTP 200 and HTTP 429.
Read quotas from each venue’s docs; see the Binance rate limit.
Demo and test environments
| Binance | OKX | |
|---|---|---|
| REST | Separate hosts: Spot Testnet testnet.binance.vision, Spot Demo Mode demo-api.binance.com, USDⓈ-M demo-fapi.binance.com | Same host openapi.okx.com + header x-simulated-trading: 1 |
| WebSocket | Separate testnet/demo hosts | Separate host: wss://wspap.okx.com:8443/ws/v5/… |
| Wrong-environment error | Key rejected on the other host | 50101 “APIKey does not match current environment.” |
This is the difference most likely to cause a real incident. With
Binance, a test key sent to production fails authentication. With OKX REST,
the environment is one header — drop it and the request goes to production.
OKX’s code for a wrong-environment key is 50101, but it publishes no cause
list, and we have not tested whether a demo key without the header returns
50101 or a signature error. A production key without the header is simply
live. OKX demo also does not support some functions, such as withdrawals. See
testnet environments compared and
the Binance testnet guide.
Account and position modes
| Binance USDⓈ-M | OKX | |
|---|---|---|
| Mode setting | dualSidePosition "true"/"false" on POST /fapi/v1/positionSide/dual | posMode long_short_mode/net_mode on POST /api/v5/account/set-position-mode |
| Order field | positionSide: BOTH, LONG, SHORT | posSide: net, long, short |
| Side error | -4061 “Order’s position side does not match user’s setting.” | 51000 “Parameter {param0} error” when posSide is omitted in long/short mode |
| Applies to | Every symbol; flips USDⓈ-M and COIN-M together | FUTURES/SWAP only; do not send posSide for SPOT/MARGIN |
OKX also has an account mode (acctLv 1–4: Spot, Futures, Multi-currency
margin, Portfolio margin). Spot mode cannot trade perpetuals, and portfolio
margin allows net mode only, so a correct order can fail because of the
account’s mode. We found no Binance setting of this kind in our sources, so we
do not pair one with it. See hedge mode.
Error-code families
Binance codes are negative (-1021, -2015, -4164), returned as
{ "code", "msg" } with a meaningful HTTP status; 5XX means the outcome is
unknown.
OKX REST codes run 50000–59999 and can carry sub-codes, such as 51008_1000
for insufficient balance. HTTP status is a weak signal: auth errors return 401
(except 50115, 405), many trade errors return 200, and when a response has
sCode, OKX says sCode and sMsg carry the result. See OKX API error 50113.
Regional hosts
OKX routes US and Australian users registered on app.okx.com to
us.okx.com — openapi.okx.com “will not work” for them — and EU users
registered on my.okx.com to eea.okx.com. Which entity serves which country
is for each venue’s own terms pages.
Which to pick
| Your situation | Lean toward | Why |
|---|---|---|
| You want environment mix-ups to fail closed | Binance | Test and demo are separate REST hosts |
| Your clock discipline is weak | OKX | 30-second tolerance vs a 5000 ms default window |
| You want IP restriction required before withdrawals | Binance | Documented rule |
| You batch orders across many instruments | OKX | Trading limits are per instrument ID, not per IP |
| You only want to manage two secrets | Binance | OKX adds a passphrase that cannot be recovered |
Can you use both
Yes. Keep a per-venue credential object — three fields for OKX, two for Binance — and make the demo header part of OKX environment config, not an optional flag. Log native codes. CCXT can handle both signing schemes; see getting started with CCXT.
FAQ
What is the OKX API passphrase?
It is a third credential you choose when creating an OKX API key, sent in the
OK-ACCESS-PASSPHRASE header alongside the key and signature. OKX stores only a
salted hash and cannot recover it, so a lost passphrase means creating a new
key. Binance’s documented authentication has no passphrase.
Why does OKX reject my timestamp when Binance accepts it?
OKX expects an ISO 8601 UTC string with milliseconds, such as
2020-12-08T09:08:57.715Z, not Unix milliseconds. It rejects values more than
30 seconds from server time with 50102, and names local timezone offset as the
most common cause. A malformed string returns 50112.
How does OKX demo trading differ from Binance testnet?
Binance uses separate hostnames for its test and demo environments. OKX demo
REST uses the production host with the header x-simulated-trading: 1, and a
separate host only for WebSocket. Forgetting the header sends a request to
production. OKX’s code for a key used in the wrong environment is 50101.
Is OKX posSide the same as Binance positionSide?
They do the same job with different values. Binance uses BOTH, LONG or
SHORT; OKX uses net, long or short, and only for FUTURES and SWAP.
Omitting the side in OKX long/short mode returns 51000; a mismatch on Binance
returns -4061.