Crypto Exchange Request Signing in JavaScript: A Professional Engineering Guide

This is symmetric-key signing. You and the exchange share the secret. It must stay on the backend. Putting it in a browser or mobile app means anyone can sign as you. Use environment variables or a vault. Do not hardcode secrets.

HMAC-SHA256 is the default for Binance, Bybit, OKX, Bitget, KuCoin, BitMart, and HTX.

That is not the whole map:

• Binance also accepts RSA and Ed25519. Ed25519 is required if you want a one-time WebSocket API login. HMAC and RSA still sign every WS API request.
• Kraken signs with HMAC-SHA512 over a SHA-256 digest. The secret is base64-encoded.
• Gate.com signs with HMAC-SHA512. The string is method, path, query, hashed body, and timestamp, joined by newlines.
• Coinbase Advanced Trade uses JWT (ECDSA or Ed25519). The older Exchange API still uses HMAC with CB-ACCESS-* headers.
• HTX accepts HMAC-SHA256 or Ed25519.

The pieces that usually go into the signed string:

• HTTP method (GET, POST, DELETE), often uppercase.
• Endpoint path, for example /api/v5/trade/order on OKX (not /api/v5/order/place).
• Timestamp. Milliseconds on Binance and Bybit. ISO 8601 on OKX. Seconds on Gate.com and Coinbase Exchange.
• Payload: query string or JSON body, byte for byte.

Miss one character and the hashes diverge. That is why Siebly.io SDKs keep a per-exchange signer instead of one generic function.

Credentials go in process.env.

Bybit V5 HMAC (matches bybit-api): concatenate timestamp, API key, recv window, then the raw query string or JSON body. No extra separators. HMAC-SHA256, hex digest.

import { createHmac } from "crypto";

const apiKey = process.env.API_KEY;
const apiSecret = process.env.API_SECRET;
const recvWindow = 5000;
const timestamp = Date.now();

const body = JSON.stringify({
  category: "spot",
  symbol: "BTCUSDT",
  side: "Buy",
  orderType: "Limit",
  qty: "0.001",
  price: "50000",
});

const payload = `${timestamp}${apiKey}${recvWindow}${body}`;
const sign = createHmac("sha256", apiSecret).update(payload).digest("hex");

const headers = {
  "X-BAPI-API-KEY": apiKey,
  "X-BAPI-SIGN": sign,
  "X-BAPI-TIMESTAMP": timestamp,
  "X-BAPI-RECV-WINDOW": recvWindow,
  "X-BAPI-SIGN-TYPE": 2,
};

OKX HMAC (matches okx-api): ISO timestamp + method + path + body. HMAC-SHA256, base64. You also send the passphrase.

import { createHmac } from "crypto";

const apiKey = process.env.API_KEY;
const apiSecret = process.env.API_SECRET;
const apiPass = process.env.API_PASS;
const timestamp = new Date().toISOString();
const method = "POST";
const endpoint = "/api/v5/trade/order";
const body = JSON.stringify({
  instId: "BTC-USDT",
  tdMode: "cash",
  side: "buy",
  ordType: "limit",
  px: "50000",
  sz: "0.01",
});

const payload = `${timestamp}${method}${endpoint}${body}`;
const sign = createHmac("sha256", apiSecret).update(payload).digest("base64");

const headers = {
  "OK-ACCESS-KEY": apiKey,
  "OK-ACCESS-SIGN": sign,
  "OK-ACCESS-TIMESTAMP": timestamp,
  "OK-ACCESS-PASSPHRASE": apiPass,
};

If you already use a Siebly SDK on Node and want createHmac instead of Web Crypto, inject customSignMessageFn. Encoding must match that exchange. Bybit HMAC is hex:

import { createHmac } from "crypto";
import { RestClientV5 } from "bybit-api";

const client = new RestClientV5({
  key: process.env.API_KEY_COM,
  secret: process.env.API_SECRET_COM,
  customSignMessageFn: async (message, secret) => {
return createHmac("sha256", secret).update(message).digest("hex");
  },
});

OKX, Bitget, and KuCoin need digest('base64') in that hook. BitMart HMAC is hex. Kraken is SHA-512 and base64 over a binary input. Do not copy one digest format across packages.

A timestamp (or nonce) stops replay. The exchange rejects a request whose clock is outside a short window. Binance and Bybit default that window to 5000ms (recvWindow / recv_window). Binance allows up to 60000ms. OKX does not use recvWindow. It signs an ISO timestamp instead.

Clock drift is the usual failure. A correct signature still dies if your clock is ahead or behind.

Siebly SDKs can apply a time offset, but it is off by default. In bybit-api, set enable_time_sync: true. In binance, time sync is disabled unless you set disableTimeSync: false. You can also fetch server time yourself (/api/v3/time on Binance spot) and set an offset. Syncing the OS clock is still the better fix.

Some DIY guides say "always sort keys alphabetically." That is not a universal rule, and it is not what these SDKs do for Bybit or Binance. Bybit GET appends the query string directly after the recv window. If you sort and the exchange does not, or the other way around, the signature breaks.

URLSearchParams is fine for encoding. It will not save you if the exchange wants a different order or a JSON body instead of a query string.

POST signing is usually JSON.stringify(body) with no extra spaces. If you pretty-print JSON for logs and then sign the pretty version, the exchange sees compact JSON and the hashes will not match. Sign the exact bytes you send.

That is the main reason to use bybit-api, binance, okx-api, and the other Siebly.io clients: each one already builds the string the exchange expects.

Do not commit secrets. Use dotenv or a secret manager. Do not log the string you sign. That string is the HMAC input. Rotate keys on a schedule.

Use testnet or demo accounts first. Bybit demo trading is demoTrading: true on RestClientV5. Binance has testnet and demo clients. Keep signing code away from strategy code so you can audit it.

For system layout, see Siebly.io research on trading system architecture.

Siebly.io SDKs sign privately by default once you pass credentials. They will not invent key permissions for you. That is still on the exchange dashboard.

You can still subscribe to streams with events. For order entry, the WebSocket API clients return a promise. The SDK signs the connection (and, where required, each request). You call submitNewOrder the same way you would call REST.

Bybit (bybit-api WS API example):

import { WebsocketAPIClient } from "bybit-api";

const wsClient = new WebsocketAPIClient({
  key: process.env.API_KEY_COM,
  secret: process.env.API_SECRET_COM,
});

const response = await wsClient.submitNewOrder({
  category: "linear",
  symbol: "BTCUSDT",
  orderType: "Limit",
  qty: "0.001",
  side: "Buy",
  price: "50000",
});

OKX and Binance expose the same shape via WebsocketAPIClient (submitNewOrder / submitNewSpotOrder). On Binance, HMAC and RSA still sign each WS API call. Ed25519 can authenticate the session once, then skip per-request signatures. That is why Binance recommends Ed25519 if you care about WS API latency.

Kraken, Gate.com, Bitget, HTX, and KuCoin also ship WebSocket API clients in the same style. Public market streams still do not need a key.

The clients are TypeScript-first and stable enough for generated agent code. For V5 Bybit work, start with the Bybit JavaScript SDK. The rest of the set is on Siebly SDKs for JavaScript and TypeScript.

That message is from Binance. Bybit uses the same idea. Default window is 5000ms. Binance lets you raise it to 60000ms. Raising the window hides drift. Fixing the clock is better.

Fetch /api/v3/time on Binance spot (or the matching time endpoint on futures), compute serverTime - Date.now(), and apply that offset. In bybit-api you can set enable_time_sync: true or wsClient.setTimeOffsetMs(...). In binance, set disableTimeSync: false. Time sync is not on by default.

The API key identifies the account. The secret is the HMAC (or JWT/RSA/Ed25519) key. Only the signature travels on the wire. OKX, Bitget, and KuCoin also need the passphrase you set when creating the key. That is not your login password.

No. The secret ends up in the browser. Sign on a Node backend. Keep keys in environment variables or a vault.

It hashes your canonical request string with your secret. The exchange repeats that hash. Match means authentic and unmodified. Kraken and Gate.com do the same thing with SHA-512. Coinbase Advanced Trade uses a signed JWT instead.

The hash function is rarely the bug. The string is. Typical causes:

• Query key order does not match what you sent.
• Pretty-printed JSON in the signature, compact JSON on the wire.
• Hex digest where the exchange wants base64 (OKX, Bitget, KuCoin), or the reverse (Bybit HMAC, Binance HMAC, BitMart).
• Wrong path. OKX place-order is /api/v5/trade/order.
• Missing passphrase or memo.

Siebly SDKs build that string per exchange.

No. Books, trades, and candles are public GET or public WebSocket topics. Sign private account calls: orders, balances, positions. Public endpoints often have tighter IP rate limits.

Call the public time endpoint. Binance spot is /api/v3/time (api/v3/time in the binance client). Store serverTime - localTime and add it when you stamp requests. Enable the SDK time-sync flags if you want that offset refreshed on a timer. Still fix the OS clock if drift is large.

Yes on these exchanges. The handshake differs. REST signs every request. Private WebSocket topics usually send one auth message or a signed URL. Awaitable WebSocket API calls may still sign per request (Binance HMAC/RSA). Ed25519 session login on Binance is the exception.

Disclaimer

*Technical and legal disclaimer: Siebly.io provides software development tools, SDKs, documentation, and educational engineering content for crypto exchange API integrations. This content is for software engineering education only and is not financial, investment, legal, tax, accounting, compliance, or trading advice.

Nothing in this article is a recommendation, invitation, or inducement to buy, sell, hold, trade, long, short, or allocate to any cryptoasset, exchange product, strategy, bot, or automated workflow. Examples, code patterns, simulations, backtests, and architecture diagrams are illustrative only and must not be treated as trading signals, investment recommendations, or evidence of future performance.

Cryptoasset markets are high risk and volatile. If you choose to build or operate exchange-connected software, you are responsible for your own legal, regulatory, tax, security, exchange-account, API-key, and risk-management obligations. Use public data, testnet, demo, dry-run, or paper-trading workflows before any live execution. Keep API keys server-side, use least-privilege permissions, and never enable withdrawals for automation keys unless you fully understand and accept the risks.

Siebly.io is not an exchange, custodian, investment adviser, trading-signal provider, or managed trading service. Official exchange documentation remains the source of truth for exchange-specific rules, API behavior, and terms of use. Use of Siebly.io content and software is also subject to the Siebly.io terms and conditions.*