Skip to main content
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.

​
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
7too many requests
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.