Timeout & Heartbeats

The server closes idle connections after 60 seconds of inactivity. This page explains how heartbeats work and how to handle disconnections.

Heartbeat

The server sends a WebSocket Ping frame every 30 seconds. Clients must respond with a Pong within 60 seconds or the connection is terminated.

Server                              Client
  |                                   |
  |-------- Ping frame ------------>|   every 30s
  |<------- Pong frame -------------|   automatic in most libraries
  |                                   |
  |        [60s timer resets]         |
  |                                   |
  |-------- Ping frame ------------>|   30s later
  |                                   |
  |        [No Pong within 60s?]      |
  |        [Connection closed]        |

Timing	Value
Ping interval	30s
Pong timeout	60s
Server write deadline	10s

Most WebSocket libraries respond to Pings automatically (gorilla/websocket, ws, websocket-client, etc.). No manual implementation required.

Application-Level Ping

Send a JSON-RPC ping to verify connectivity and retrieve server time. Useful for latency checks or confirming the connection is healthy.

This does not reset the 60-second timeout. Only the protocol-level Pong does that.

{
  "jsonrpc": "2.0",
  "id": "1",
  "method": "ping"
}

{
  "jsonrpc": "2.0",
  "id": "1",
  "result": {
    "timestamp": "2026-02-15T12:00:00.000Z"
  }
}

Reconnection

The server does not persist session state. When a connection drops, all subscriptions are cleared. Clients must reconnect and resubscribe.

Recommended strategy: Use exponential backoff (1s → 2s → 4s → 8s, max 30s), then resubscribe to all channels.

Getting Started

Info + Exchange Requests

Global Channels

Accounts Channels

Heartbeat

Application-Level Ping

Reconnection

​Heartbeat

​Application-Level Ping

​Reconnection

Heartbeat

Application-Level Ping

Reconnection