Skip to main content

Websockets v2 API

· 3 min read

The websockets interface has been completely re-designed to enable simpler and faster integration with applications.

The interface is more extendable and documents are more readable for machine (and human!) clients.

Cleaner Document Structure​

  • It has a FIX-like design, FIX is standard communication protocol across the financial industry, enabling a more familiar experience across all of our APIs.
  • Pair symbols have been aligned into the more readable "BTC/USD" format.
  • The timestamps use the RFC3339 format 2021-05-11T19:47:09.896860Z which are readable, parsable and easy to sort.
  • Prices and quantities are published as a number type for ease of processing. The values contain the same precision as the engine and full precision can be maintained when decoded as a decimal or a string instead of the default json parser setting (usually float). This offers ease of processing and precision where required.
  • Payloads are normalised JSON objects with no/minimal positional or variable length fields, to allow for maximum future flexibility without breaking client code.
  • The message structure is consistent (i.e. predictable dictionary keys) and is more readable for both human and machine clients.

Example: Add a trailing-stop order which triggers when the market reverts 1% from trough price

{
    "method": "add_order",
    "params": {
        "order_type": "trailing-stop",
        "side": "buy",
        "order_qty": 100,
        "symbol": "MATIC/USD",
        "triggers": {
            "reference": "last",
            "price": 1.0,
            "price_type": "pct"
        },
        "token": "G38a1tGFzqGiUCmnegBcm8d4nfP3tytiNQz6tkCBYXY"
    }
}

Order Transactions and Requests​

Requests​

  • All requests accept an optional, client-specified integer request identifier (req_id) for matching up the response, when returned. The uniqueness of the req_id is not enforced by the exchange.
  • Warnings are generated on add_order transactions when deprecated fields are detected.

Responses​

All responses to requests have a standardised response:

  • time_in and time_out describe when our server received the request and sent the response, to help further isolate and measure network/client/server latency.
  • success indicates if the request was handled successfully.
  • result includes details specific to the type of request.
  • error if present, gives details of what error occurred.

Additionally, the responses now contain advisory messages, highlighting deprecated fields or upcoming changes to the request / channel.

Channels​

Additional event driven streams have been added:

  • level3: streams the orders that constitute the central limit order book. This offers an additional level of granularity over level2 book channel. This feed enables queue priority and a range of order book analytics to be calculated.
  • balance: streams the client asset balances and transactions from your account ledger.