Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.whitebit.com/llms.txt

Use this file to discover all available pages before exploring further.

Reference documentation for WebSocket connection limits, request limits, timeout behavior, and error codes.
Rate limit: 1000 WebSocket connections per minute and 200 JSON-RPC requests per minute per connection.

​
Connection limits

ScopeLimit
New connections1,000 per minute
Requests per connection200 per minute
Limit WebSocket connection creation to 1000 connections per minute. Limit JSON-RPC requests to 200 requests per minute per connection. Reuse a single WebSocket connection for multiple subscriptions. Opening a new connection per channel consumes the connection limit and increases latency.

​
Subscription limits

ScopeLimit
Active subscriptions per connectionNone
Markets per subscription requestNone
Per-channel-type limitsNone — the same 200 requests per minute limit applies uniformly across all public and private channels
A single connection comfortably maintains subscriptions across 200 or more markets. Distributing markets across multiple connections is not required for high-market-count workloads. 
{
  "id": 1,
  "method": "lastprice_subscribe",
  "params": ["BTC_USDT", "ETH_USDT", "SOL_USDT", "XRP_USDT"]
}
The request above counts as one message regardless of the number of markets in params.
Repeating a subscription replaces the previous one for the same channel. To track additional markets on an active channel, send a new subscribe request with the full target list — the server does not merge incremental subscribes.

​
Rate limit handling

Implement request throttling on the client side. Queue subscription requests instead of sending bursts of requests. Apply exponential backoff with jitter after receiving error code 7. Reuse active connections instead of creating new connections.

​
Rate limit error example

{
  "error": { "code": 7, "message": "too many requests" },
  "result": null,
  "id": 2269
}

​
Connection timeout

The server closes the WebSocket connection after 60 seconds of inactivity. Inactivity means no messages sent by the client. Send a ping request every 50 seconds to keep the connection alive: 
{
  "id": 0,
  "method": "ping",
  "params": []
}
Expected response: 
{
  "id": 0,
  "result": "pong",
  "error": null
}
Code example:
JavaScript
const socket = new WebSocket("wss://api.whitebit.com/ws");

setInterval(() => {
  if (socket.readyState === WebSocket.OPEN) {
    socket.send(JSON.stringify({
      id: 0,
      method: "ping",
      params: []
    }));
  }
}, 50000);

​
Error codes

The server returns errors in the error field of a response message. The error object contains a code and a message.
CodeMessage
1invalid argument
2internal error
3service unavailable
4method not found
5service timeout
6require authentication
7too many requests
The server returns code 6 when a client invokes a protected method — a private-channel subscription or a balance query, for example — without first calling authorize on the connection. Send an authorize request before any private-channel subscription. See WebSocket Authentication for the authorization flow. Error response format: 
{
  "id": 1,
  "result": null,
  "error": {
    "code": 1,
    "message": "invalid argument"
  }
}
The server closes the WebSocket connection immediately if the client sends invalid JSON.

​
Best practices

Reuse connections. Each subscription does not require a new connection. Subscribe to multiple channels on a single connection to stay within the 1,000 connections per minute limit. Implement reconnection logic. Handle unexpected disconnections with exponential backoff (for example, wait 1s, 2s, 4s, 8s between retries). Re-subscribe to all channels and re-authorize private channels after reconnecting. Batch subscriptions. Subscribe to all required channels immediately after connecting rather than one at a time. Batching reduces round-trips and avoids hitting the 200 requests per minute per connection limit during setup. Monitor ping latency. A slow or missing pong response indicates network issues. Reconnect if the server does not return pong within 10 seconds after a ping.