Skip to main content

WebSocket API

The WebSocket API makes it possible to open a two-way interactive communication session between API clients and the exchange.

With this API, you can send messages to our servers and receive event-driven responses without having to poll the server for a reply.

Message Format

The request and response messages in between clients and the WebSocket API are all in JSON format.

caution

All values in request or response messages are transmitted as string.

Example: if the documentation states that the price field of a request calls for a float type, the client should send:

{
"price": "125.60"
}

Any value sent as a number or a boolean will not be accepted.

Example: The following request will be rejected

{
"price": 125.6
}

Identifying Messages

Message dialogues are asynchronous in nature and if several requests are issued in quick succession, the responses may be returned out of order.

All request messages will receive a response, and then depending upon the request they may also receive continuing unsolicited updates (e.g: listening to new RFQs on the platform).


Below, two ways of identifying which response corresponds to which request:

User Tags

Requests that expect a single reponse message contain a user_tag field. That field is populated by clients to uniquely identify the response.

info
  • It is the client's responsibility to ensure the user_tag values are unique.
  • user_tag values can be anything from 1 to 64 bytes in length

Client Order ID’s

Order related requests typically expect several responses corresponding to different steps in the order lifecycle: entered, accepted, rejected, filled ...

These requests and subsequent responses include a client_order_id field that is used to uniquely identify which reponse corresponds to which request/order

info
  • It is the client's responsibility to ensure the client_order_id values are unique.
  • client_order_id values can be anything from 1 to 32 bytes in length

Heartbeats

The system publishes heartbeat messages every 5 seconds if the client is idle (does not send any message).

NameTypeComments
server_utc_timestampintegerThe system time in μs (1/1000th of a millisecond)

Example:

{ "heartbeat": { "server_utc_timestamp": "1670143999492414" } }

Errors

If a command fails, an error message is sent. It contains error information and the user_tag field to identify which request it corresponds to.

NameTypeComments
error_codeintegerError code
error_textstringError Description
user_tagstringClient defined tag used to identify the request

Example

{
"command_response": {
"error_code": "12",
"error_text": "error parsing new order request",
"user_tag": "unique_request_id"
}
}