Streaming

note

This section is related to trading integration. For more information about the streaming endpoint for data integration, see Stream of prices

Regular Endpoints

Regular endpoints operate as typical REST API requests. The client initiates an HTTP connection to the server, which closes the connection after providing a response.

Streaming Endpoints

Streaming endpoints function differently. The client initiates the connection, and the server continuously sends messages without closing it. Typically, one streaming connection per endpoint remains open until the user session ends. Unlike regular endpoints, streaming endpoints have no response header requirements. Messages sent in the response body are formatted in JSON without newline characters, with different messages separated by a newline character.

Advantages of Streaming Endpoints

Streaming endpoints offer several benefits over regular polling requests:

• Immediate updates push upon occurrence, reducing latency for instant UI changes and a smoother user experience.
• A single persistent connection reduces the number of HTTP requests, lowering bandwidth usage and enabling seamless scaling for more users or data payloads.
• Fewer requests decrease computational load and resource usage for both clients and servers.

Use Cases for Streaming Endpoints

Streaming endpoints may be particularly useful in the following scenarios:

• When the broker server imposes request frequency limits, resulting in 429 response codes, or when traffic is billed on a per-request basis.
• When concurrent connections from multiple tabs are required, as streaming endpoints reduce the number of requests compared to regular REST endpoints.
• When minimizing data transmission is necessary, as streaming endpoints send only updates rather than full data snapshots.

info

Please make sure the regular endpoints are supported for 1 month after switching to the streaming endpoints. Handling the requests from both types of endpoints will secure an uninterrupted integration operability, since the switch happens only after the page reload.

Data flow of Streaming Endpoints

1. Client opens a connection
2. Server initially responds with snapshot of data
3. While connection is open, server continues to send update and ping messages
4. Client or server closes a connection

Examples of the expected response for the case of /stream/orders endpoint are provided in the following sections.

Snapshot of data

The client initiates the connection. Server responds with a JSON message containing all orders for this account from the current trading session as well as open orders from the previous sessions. The formatted response is shown below:

[
  {
    "id": "1",
    "instrument": "EURUSD",
    "qty": 101,
    "side": "buy",
    "type": "limit",
    "avgPrice": 0,
    "limitPrice": 1.2093,
    "duration": {
      "type": "gtt",
      "datetime": 1548406235
    },
    "status": "working"
  },
  {
    "id": "2",
    "instrument": "AAPL",
    "qty": 2,
    "side": "sell",
    "type": "market",
    "avgPrice": 170.29,
    "duration": {
      "type": "gtc"
    },
    "status": "filled"
  }
]

Update and ping messages

It is only required to send an update if a new order is placed or if there is an update for a particular order. The message should contain full information for that particular order, and not only for the updated fields:

[
  {
    "id": "1",
    "instrument": "EURUSD",
    "qty": 101,
    "side": "buy",
    "type": "limit",
    "avgPrice": 1.2087,
    "limitPrice": 1.2093,
    "duration": {
      "type": "gtt",
      "datetime": 1548406235
    },
    "status": "filled"
  }
]

It is expected to receive a ping message that indicates an active connection in the case of no updates for five seconds:

{"s": "ok"}

Closing a connection

If the connection is closed by the server, the client will attempt to reconnect several times. If the reconnect attempt is unsuccessful, the user will be logged out from the integration.