Heartbeats

If a websocket client disconnects, and they have enabled cancel-on-disconnect during authentication, orders placed by that connection will be cancelled upon detection of the disconnect. This is independent of any heartbeat messages.

In addition, we support optional bi-directional heartbeats:

• The websocket client can send heartbeat_request messages to the server and get heartbeat_response messages back if it wishes to probe the aliveness of the server. The websocket client can choose to disconnect if it does not receive a response.
• The websocket client can request that the server send it heartbeat_request messages on an interval, upon which the client is expected to send a heartbeat_response message. If a heartbeat_response message from the client is not received, the client is disconnected.

heartbeat_request and heartbeat_response messages follow the same format, whether they are initiated by the server or the client.

Heartbeat Requests

These heartbeats are formatted similarly to normal requests, with the following characteristics:

• msg_type: heartbeat_request
• id: The ID of the request, an integer
• version: The API version (currently 1)
• There is no request body. The "body" element may be null or an empty object.

The heartbeat message from the client to the exchange is formatted as follows:

[
  {
    "msg_type": "heartbeat_request",
    "id": 1002,
    "version": 1
  }
]

Heartbeat Responses

These heartbeats are formatted similarly to normal responses, with the following characteristics:

• msg_type: heartbeat_response
• id: The ID of the corresponding heartbeat request, an integer
• version: The API version (currently 1)
• There is no response body. The "body" element may be null or an empty object.

The heartbeat message from the client to the exchange is formatted as follows:

[
  {
    "msg_type": "heartbeat_response",
    "id": 1002,
    "version": 1
  }
]