Skip to main content

HTTP API

The ALOR Broker trading system provides an HTTP API for retrieving data and managing requests via the HTTP protocol.

This communication channel provides access to system resources in a “request-response” mode and is designed to perform discrete operations.


Interface Features

The HTTP API is based on a message-passing model without session state preservation. Each client request is processed as an independent transaction, which requires the context or authorization data to be re-transmitted with every request.

This interaction model has its advantages and disadvantages in practical use of the interface.

AdvantageDisadvantage
Request isolation prevents the loss of multiple active subscriptions in the event of a single connection breakThe need to establish a new connection for each operation increases the load on the network infrastructure
Ability to transfer large volumes of data (e.g., historical records) as a single batchReceiving messages larger than 30 MB places a high computational load on client software, and transmitting them places a high load on server infrastructure
Simplified integration and automation due to the absence of the need to manage the session lifecycleLimiting the data refresh rate to the client’s polling speed
Use of standardized HTTP status codes for handling errors and request statusesSending full headers with every request increases the volume of overhead traffic
Stable operation through standard network gateways and firewalls without specific port configurationNo proactive notifications from the server regarding critical changes or order execution
caution

In addition to the features listed above, this interface has a limited maximum interaction rate — no more than 100 requests per second from each user.


Use Cases

The choice of protocol for interacting with the system should be based on the type of task you are solving and the intensity of trading operations. Below are several scenarios for working with the system in which the use of the HTTP API is either permitted or prohibited:

PermittedProhibited
Initial download of complete directories of trading instruments and platformsSimulating a real-time stream of market data updates through frequent repeated requests
Retrieving specific data about an instrument or positionDownloading the full volume of data without restrictions or filtering
Retrieving historical data for a limited periodDownloading large volumes or regularly requesting the same historical data
Placing individual orders, grouping them into groups, or canceling all orders with a single requestHigh-frequency order placement and cancellation via separate requests
Synchronizing local portfolio and position status after failuresMonitoring rapidly changing parameters, such as the order book or current quotes
tip

For high-intensity interaction scenarios with minimal latency, use the WebSocket API.

tip

A range of reference data can be obtained using the GraphQL API.


Recommendations

Regardless of the task, follow these rules to ensure stable interaction and reduce the risk of access being blocked:

  • Cache static data. Store reference data locally and update it no more than once per trading session or upon receiving a cache invalidation notification.
  • Adhere to load limits. Do not exceed the threshold of 100 requests per second. To reduce request intensity, use client-side throttling mechanisms.
  • Optimize queries. Use filtering and pagination parameters to request only the necessary amount of data. Avoid regularly fetching full lists unless absolutely necessary.
  • Manage access tokens. Reuse the received token throughout its entire lifetime (30 minutes) instead of generating a new one for each request.
tip

Combine all available system interfaces to solve your tasks as efficiently as possible.

caution

Ignoring these recommendations and/or using the HTTP API for purposes other than its intended use will result in your access to the system being blocked. For more details, see the article “Limits and Recommendations”.