Crypto Exchange SDK: JS, TS, & Node.js Engineering Guide

Signing requests yourself, then keeping a WebSocket alive, is where most exchange integrations start to rot. Each venue uses a different signature, a different clock or nonce rule, and a different shape for the same idea of "place an order". The Siebly SDKs are separate Node.js clients, one package per exchange, written in TypeScript. They sign the request and keep the socket up. They do not throttle you. That part stays in your process.

• Request signing is not one HMAC recipe. Kraken, Gate, Binance, and Coinbase Advanced Trade do not sign the same way.
• Bybit's current client is V5 (RestClientV5). SpotClientV3 is deprecated.
• Awaitable order calls over WebSocket exist on some of these packages, and not on Coinbase or BitMart.
• None of these SDKs queue or slow your requests to stay under an exchange rate limit. binance does record the weight headers Binance sends back.

Exchange docs describe the HTTP API. They are not a client. If you sign by hand, the bugs show up as rejected private calls, and the reason is usually the signature string, not the order itself.

These are the schemes the current packages implement:

• binance signs REST with HMAC-SHA256, RSA, or Ed25519. A PEM private key is detected and switches the algorithm. The default recvWindow is 5000 ms. Time sync exists, and it is off unless you set disableTimeSync: false.
• bybit-api V5 signs with HMAC-SHA256, or RSA-SHA256 when the secret is a PEM private key. Time sync is off unless you set enable_time_sync.
• okx-api, bitget-api, and kucoin-api use HMAC-SHA256 plus the API passphrase. That passphrase is not your login password.
• gateio-api uses HMAC-SHA512.
• @siebly/kraken-api hashes the payload with SHA-256, then signs with HMAC-SHA512. The API secret is base64. Spot signing uses a nonce.
• @siebly/htx-api uses HMAC-SHA256.
• bitmart-api uses HMAC-SHA256 over timestamp#memo#params. You pass apiMemo from the key you created.
• coinbase-api is split by product. Advanced Trade and the Coinbase App sign a JWT, and the client accepts ECDSA or Ed25519 keys. Coinbase Exchange, International, and Prime use HMAC-SHA256 plus a passphrase.

A clock that is off by a few hundred milliseconds is not a universal failure mode. Binance and Bybit reject a request when the timestamp falls outside recvWindow (5000 ms on the Binance client unless you change it). Kraken spot fails on a bad nonce, not on that same window. Sync the host clock first. If a Binance or Bybit call still reports a recvWindow error, both WebSocket API clients expose setTimeOffsetMs().

Bybit's old spot V3 client is still exported as SpotClientV3, and the source marks it deprecated. Those endpoints were scheduled to be turned off by the end of 2024. New code should use RestClientV5. The V5 methods take a category (spot, linear, inverse, option) because that is how Bybit's Unified Trading Account API is shaped. Calling that "Unified Margin" is the older account name, and it is the wrong one to use against this client.

Each package splits stateless REST calls from the WebSocket client that holds the connection, heartbeats, and reconnect.

The SDK signs, stamps the timestamp or nonce, and parses the JSON into the typed method you called. It does not decide how fast you are allowed to call. A 404 is a missing path or resource. Rate limits come back as 429, or as an exchange error code in the body. Do not treat those as the same failure.

On binance, the REST client stores the weight and order-count headers from the last response on apiLimitTrackers (x-mbx-used-weight-1m, x-mbx-order-count-10s, and the other x-mbx-* counters). That is a reading, not a limiter. Nothing in that client waits, queues, or sheds a call when the weight gets high. If you need a queue, you write it.

binance and bybit-api publish a CommonJS build (main points at lib/index.js). Node can import that build, and the examples also show require(). The other packages publish both an ESM and a CJS entry (import and require in exports).

A single wrapper that pretends every exchange has the same createOrder() will hide the parameters you actually need. Bybit V5 wants category. Binance Portfolio Margin is a separate client, PortfolioClient, next to MainClient (spot, cross margin, isolated margin, and the other main-site products), USDMClient, and CoinMClient. Vanilla options are not in the Binance REST clients yet.

Bitget's awaitable WebSocket orders are the V3 / Unified Trading Account API. RestClientV2 and WebsocketClientV2 are still in the package for the classic account. WebsocketAPIClient on Bitget expects V3 keys.

The npm names below are the ones in each package.json. Kraken and HTX are scoped. The others are not.

Specialized clients are the right tool when you place or amend orders. A unified library is fine for a read-only screen that only needs last price from many venues. When Bybit or Binance changes a parameter, the matching package can ship that change on its own. A wrapper that maps ten exchanges through one method waits on every other venue first.

Use REST for snapshots and for anything the venue does not expose as a request/response socket call. Use the WebSocket client for streams. Where the table above says the WebSocket API exists, WebsocketAPIClient returns a Promise for that call. You await the matching response. You do not have to correlate ids yourself.

Public REST needs no keys. This is the Bybit V5 ticker call from the SDK examples. category is required, and it is how you pick the V5 product:

import { RestClientV5 } from "bybit-api";

const client = new RestClientV5();

const tickers = await client.getTickers({ category: "linear" });
console.log(tickers);

The same pattern on Binance spot uses MainClient. Credentials are optional until you call a private method:

import { MainClient } from "binance";

const client = new MainClient();

const ticker = await client.get24hrChangeStatistics({
  symbol: "BTCUSDT",
});
console.log(ticker);

Bybit's WebSocket API client is the same V5 surface, as a Promise. The snippet below is the SDK's own order example. With live keys this sends a real limit order. testnet: true is available on this client. Demo trading is not: as of the SDK example notes (Jan 2025), Bybit demo trading can consume events and does not accept WebSocket API orders.

import { WebsocketAPIClient } from "bybit-api";

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

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

Binance has the same style of client. HMAC and RSA work, and each command is signed on its own. Ed25519 is the one that can authenticate the socket up front, which is why the SDK examples call it the faster path for this API. Pass the Ed25519 private key as api_secret.

import { WebsocketAPIClient } from "binance";

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

const response = await wsClient.submitNewSpotOrder({
  symbol: "BTCUSDT",
  side: "SELL",
  type: "LIMIT",
  timeInForce: "GTC",
  price: "23416.10000000",
  quantity: "0.00847000",
});
console.log(response);

OKX will reject the call if you only pass a key and secret. The REST and WebSocket API clients expect the passphrase on the account object:

import { WebsocketAPIClient } from "okx-api";

const wsClient = new WebsocketAPIClient({
  accounts: [
{
apiKey: process.env.API_KEY_COM || "",
apiSecret: process.env.API_SECRET_COM || "",
apiPass: process.env.API_PASSPHRASE_COM || "",
},
  ],
});

const res = await wsClient.submitNewOrder({
  instId: "BTC-USDT",
  tdMode: "cash",
  side: "buy",
  ordType: "limit",
  px: "10000",
  sz: "0.001",
});
console.log(res);

The place-order type marks instId as deprecated since March 2026 in favor of instIdCode (a numeric instrument id, which wins if you send both). The SDK examples still pass instId. Check OKX's current instrument mapping before you rely on the string id.

Bitget's version of that call is submitNewOrder('spot', {... }) on WebsocketAPIClient, and it needs apiKey, apiSecret, and apiPass from a V3 key. KuCoin uses apiPassphrase and methods such as submitNewSpotOrder. Gate uses submitNewSpotOrder and also has futures methods on the same client. Kraken's submitSpotOrder is spot only. HTX's submitSpotOrder needs the spot account-id from your account.

Keep the process that places orders separate from the process that chews through order book diffs. The socket client can stay current and still be useless if your parser blocks the event loop. Public data and testnet or demo, where that venue actually supports it, should be the first place these calls run. See historical and live data pipelines if you are splitting ingest from execution.

The stream clients emit reconnect and reconnected and resubscribe after the socket returns. That covers Binance (including the 24 hour disconnect and listenKey refresh), Bybit, OKX, Bitget, Gate, KuCoin, Kraken, HTX, Coinbase, and BitMart. A reconnect does not rewind the trades you missed. Snapshot the book or the account over REST when the socket comes back, then continue from the stream.

Coinbase and BitMart do not have WebsocketAPIClient. You cannot await an order acknowledgement on those two. Coinbase Advanced Trade public data looks like this:

import { WebsocketClient } from "coinbase-api";

const client = new WebsocketClient();

client.on("update", (data) => {
  console.log(data);
});

client.on("reconnected", (data) => {
  console.log("reconnected", data?.wsKey);
});

client.subscribe(
  {
topic: "ticker",
payload: {
product_ids: ["BTC-USD"],
},
  },
  "advTradeMarketData",
);

Private Coinbase streams use the same subscribe() call with a user-data wsKey such as advTradeUserData. The client authenticates that connection when keys are present. Order placement for Coinbase stays on the REST client, for example CBAdvancedTradeClient.

BitMart is the same shape: new WebsocketClient(), listen for update, and subscribe. There is no promise wrapper for trading commands.

The request objects you pass are the types checked by the compiler. That is what an editor, and a coding agent, can follow. coinbase-api types most requests and responses, not every field of every payload, so do not assume a missing property is a bug in your code before you check the type.

The Siebly AI Prompt Framework and the pattern notes are written against these clients. Point the agent at the package and the method, not at a generic "exchange" interface. When an API version moves, track it on releases for the package you actually depend on.

These clients are a signing and transport layer. They are not a trading system, and they are not a rate limiter. Build the throttle, the order state, and the kill switch yourself.

The packages in the table above are the current set: binance, bybit-api, okx-api, @siebly/kraken-api, coinbase-api, bitget-api, gateio-api, kucoin-api, bitmart-api, and @siebly/htx-api. Install docs and per-exchange tutorials start at siebly.io/sdk.