Bitget API SDK TypeScript: Building Production-Ready Node.js Integrations in 2026

A home-grown Bitget wrapper means maintaining signing, error parsing, endpoint drift, and WebSocket lifecycle code yourself. bitget-api wraps Spot, Futures, and UTA endpoints behind consistent client classes. Types ship for requests and responses across REST and WebSocket.

The SDK does not throttle outbound traffic. Bitget rate limits vary by endpoint (often 1 to 20 requests per second per UID on V3, not a single global cap). Read response headers and queue work in your app if you burst calls.

Install from npm:

npm install bitget-api

Or with yarn:

yarn add bitget-api

Turn on strict mode in tsconfig.json so the compiler catches bad parameters early.

For UTA accounts, start with RestClientV3:

import { RestClientV3 } from "bitget-api";

const client = new RestClientV3({
  apiKey: process.env.API_KEY_COM!,
  apiSecret: process.env.API_SECRET_COM!,
  apiPass: process.env.API_PASS_COM!, // passphrase from API key setup, not your login password
});

(async () => {
  try {
const balances = await client.getBalances();
console.log(balances);

const order = await client.submitNewOrder({
category: "USDT-FUTURES",
orderType: "market",
side: "buy",
qty: "0.001",
symbol: "BTCUSDT",
});
console.log("Order submitted:", order);
  } catch (e) {
console.error("request failed:", e);
  }
})();

Public endpoints work without credentials:

import { RestClientV3 } from "bitget-api";

const client = new RestClientV3();

const tickers = await client.getTickers({ category: "SPOT" });

If you are still on a classic account, use RestClientV2 instead. Same credential shape:

import { RestClientV2 } from "bitget-api";

const client = new RestClientV2({
  apiKey: process.env.API_KEY_COM!,
  apiSecret: process.env.API_SECRET_COM!,
  apiPass: process.env.API_PASS_COM!,
});

const account = await client.getSpotAccount();

REST and WebSocket use different client classes. That mirrors how Bitget splits protocols and keeps each connection lifecycle clear.

Use least privilege on every key:

• Market data only: read permissions.
• Trading bots: enable spot or futures trading, keep withdrawals off.
• Never commit keys. Use environment variables or a secrets manager locally via dotenv, with .env excluded from git.

Bitget does not offer a separate testnet URL in this SDK. For safe development, use demo trading: create demo API keys in the demo trading environment and pass demoTrading: true. That adds the paptrading: 1 header on REST and routes WebSockets to demo endpoints.

import { RestClientV3 } from "bitget-api";

const client = new RestClientV3({
  apiKey: process.env.API_KEY_COM!,
  apiSecret: process.env.API_SECRET_COM!,
  apiPass: process.env.API_PASS_COM!,
  demoTrading: true,
});

Multiple accounts? Instantiate one client per credential set.

You should not hand-build signing strings in production. One wrong character or body encoding fails auth immediately.

The REST client signs every private call internally. For latency-sensitive Node.js backends, you can inject Node's native createHmac instead of the default Web Crypto signer:

import { createHmac } from "crypto";
import { RestClientV3 } from "bitget-api";

const client = new RestClientV3({
  apiKey: process.env.API_KEY_COM!,
  apiSecret: process.env.API_SECRET_COM!,
  apiPass: process.env.API_PASS_COM!,
  customSignMessageFn: async (message, secret) => {
return createHmac("sha256", secret).update(message).digest("base64");
  },
});

The SDK also supports RSA key signing. See examples/auth/rest-private-rsa.ts in the repo.

Clock sync: REST signing uses Date.now() on your machine. The SDK does not auto-sync your clock on startup. If you see timestamp or recvWindow errors, fix system time or call fetchLatencySummary() on RestClientV3 to measure drift against Bitget's server time:

const latency = await client.fetchLatencySummary();
console.log(latency.timeDifference); // ms between local clock and server

For WebSockets, setTimeOffsetMs() exists on WebsocketClientV3 and WebsocketAPIClient if you compute an offset yourself.

More patterns: Bitget TypeScript tutorial.

Compare a raw integration (manual headers, timestamp, signature string, response typing) with the SDK client above. The difference in code volume is large. IntelliSense on typed responses catches wrong property names during development instead of in production.

Failed exchange calls need structured errors, not a generic 500 string. With parseExceptions enabled (default), the REST client throws an object containing HTTP status, Bitget code / msg in body, and response headers so you can branch on insufficient margin, invalid size, or permission errors.

WebSocket clients emit open, reconnect, reconnected, authenticated, update, and exception events. Reconnection and resubscription run inside the client after drops.

Again: no built-in rate limiting. Track headers and shape your own backoff.

import { WebsocketAPIClient } from "bitget-api";

const wsClient = new WebsocketAPIClient({
  apiKey: process.env.API_KEY_COM!,
  apiSecret: process.env.API_SECRET_COM!,
  apiPass: process.env.API_PASS_COM!,
  // demoTrading: true,
});

// Optional: warm the WS API connection before first order
await wsClient.getWSClient().connectWSAPI();

try {
  const res = await wsClient.submitNewOrder("spot", {
orderType: "limit",
price: "100",
qty: "0.1",
side: "buy",
symbol: "BTCUSDT",
timeInForce: "gtc",
  });
  console.log("place-order response:", res);
} catch (e) {
  console.error("submitNewOrder failed:", e);
}

// Cancel by client order id
await wsClient.cancelOrder("spot", { clientOid: "my-order-id" });

Requires V3 / UTA API keys. V2 WebSockets do not expose this order channel; use RestClientV2 or RestClientV3 REST methods there.

For public market data on UTA, use WebsocketClientV3:

import { WebsocketClientV3, WS_KEY_MAP } from "bitget-api";

const wsClient = new WebsocketClientV3();

wsClient.on("update", (data) => {
  console.log("market update:", data);
});

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

wsClient.subscribe(
  {
topic: "ticker",
payload: { instType: "spot", symbol: "BTCUSDT" },
  },
  WS_KEY_MAP.v3Public,
);

// Multiple symbols in one call
wsClient.subscribe(
  [
{ topic: "ticker", payload: { instType: "spot", symbol: "BTCUSDT" } },
{ topic: "ticker", payload: { instType: "spot", symbol: "ETHUSDT" } },
  ],
  WS_KEY_MAP.v3Public,
);

The client handles heartbeats, reconnect, and resubscribe after disconnects. It delivers parsed events; it does not maintain a local order book state machine for you. For merged depth snapshots and incremental book maintenance, pair the stream with your own logic or a library like orderbooks.

Private account streams (balances, orders, positions) use WebsocketClientV3 with API credentials on WS_KEY_MAP.v3Private. See examples/V3 - UTA/Websocket/ws-private.ts.

Full walkthrough: Bitget JavaScript Quickstart.

Start on demo trading with demoTrading: true and demo keys. Exercise auth, orders, and error paths without real capital.

Mock REST responses in unit tests for edge cases (insufficient balance, bad tick size, expired keys). For architecture patterns around long-running bots, see our Algorithmic Trading System Architecture guide.

WebSocket demo mode:

import { WebsocketClientV2 } from "bitget-api";

const wsClient = new WebsocketClientV2({
  demoTrading: true,
  apiKey: process.env.API_KEY_COM!,
  apiSecret: process.env.API_SECRET_COM!,
  apiPass: process.env.API_PASS_COM!,
});

Large ingest workloads may need several WebSocket connections across symbols or account partitions. If multiple Node.js processes share order state, centralize state in Redis or similar rather than assuming one process owns the truth.

The SDK targets high-volume WebSocket use: persistent connections, reconnect, and typed events. Your app decides how to consume and act on them.

The package ships llms.txt and consistent method names, which helps AI coding agents generate correct calls. For prompt templates, see Siebly.io AI.

Before production: no withdrawal permission on bot keys, secrets out of source control, and rate limits enforced in your layer.

No. The bitget-api SDK does not throttle or queue requests. Limits depend on the endpoint (check Bitget docs and inline comments in RestClientV3 / RestClientV2). Watch response headers and implement your own queue or leaky bucket if you burst traffic.

Install bitget-api, use RestClientV3 and WebsocketClientV3 (or WebsocketAPIClient for WS orders), and pass UTA API credentials. Types for UTA request and response shapes are exported from the package.

V3 targets the Unified Trading Account: shared margin across products and the latest endpoint set. V2 remains for classic account layouts. New UTA projects should default to V3 clients; use V2 clients only if your account has not migrated.

Yes, on V3 / UTA. Use WebsocketAPIClient methods like submitNewOrder, placeBatchOrders, cancelOrder, and cancelBatchOrders. Each returns a Promise resolved when the matching WS API response arrives.

WebsocketClientV2 and WebsocketClientV3 reconnect automatically, send heartbeats, and resubscribe prior topics after a drop. Listen for reconnect and reconnected if you need to log or meter connection health.

Bitget's paper environment is demo trading, not a separate testnet hostname in this SDK. Create demo API keys, set demoTrading: true on REST and WebSocket clients, and route traffic there before using live keys.

Least privilege (no withdrawals on automation keys), environment-based secret storage, regular key rotation, and demo trading for initial development.

REST signing uses your local Date.now(). Call fetchLatencySummary() on RestClientV3 to check drift, keep OS time accurate (NTP), or set a manual offset on WebSocket clients via setTimeOffsetMs() after you compute one. There is no automatic clock sync on client construction.