Data receiption
ALOR Broker trading system gives the possibility to get exchange data via API. You can use HTTP API, WebSocket API and GraphQL API for this task.
There is no universal way of interaction. Each of the available options has its own advantages, disadvantages and peculiarities that should be taken into account. When selecting an interaction option, focus on your tasks and keep fair-use principles in mind so that your actions do not harm the system. Also, using one option of interacting for one task does not affect your ability to use another option for another task.
Data types
The following exchange data can be obtained from the trading system via API:
- List of created orders and detailed information about them
- List of concluded transactions and detailed information about them
- List of available financial instruments and information about them: quotes, order books, historical data, etc.
- Information about the user and portfolio: general information, positions, risks, etc.
If you can't get the data you're looking for (can't find a relevant query or the result looks uninformative), contact us at Telegram.
Data categories
All data provided by the trading system via API can be classified into two categories:
- Public data — information that can be freely obtained from any third-party sources, and access to them by a wide range of persons will not affect the market behavior or the state of the system. Such information includes, for example, lists of available instruments and currency pairs.
- Protected data - information, the free publication of which for an unlimited range of persons can provoke both changes in market behavior and disclosure of personal data of portfolio holders. Access to data in this category requires authorization to confirm access rights to the requested resources. Such information includes, for example, data on all trades for today and list of open positions in the portfolio.
Access to data
Although public data is not secret and can be freely obtained through other sources, access to it via ALOR Broker API may be partially restricted. This is done to reduce the load on the system and to give priority to requests made by Broker's clients.
Restrictions may be different depending on the chosen method of interaction:
- HTTP API and GraphQL API public resources do not require mandatory authorization of requests, but the response will contain data that was up to date 15 minutes ago. For example, a request sent at 15:00 to get current UTC time in Unix format will return data corresponding to 14:45.
- WebSocket API has no public resources. All requests to any of the resources provided must be authorized. This applies even to those requests, information in response to which can be obtained in other ways without authorization.
To avoid these restrictions, log in as a trader or use test access.
Request examples
Common requirements
To ensure that the system returns up-to-date data in response, the queries sent must meet certain requirements. Depending on the selected communication interface, requests must be:
- authorized (HTTP API, WebSocket API, GraphQL API)
- identifiable (WebSocket API)
- sent to united interface URL (WebSocket API, GraphQL API).
To fulfill these requirements, use additional header and/or request body parameters described below.
- HTTP API
- WebSocket API
- GraphQL API
Authorization
Authorization is necessary to confirm that the sender has the rights to use the requested resource. Request authorization uses a JWT token, which acts as an Access token. A full description of available authorization methods is available in the Authorization section.
HTTP API uses the Authorization
header parameter to pass the token. The header must be passed with each executed request.
This token should be passed as a Bearer token, so the header must contain the Bearer
prefix before the passed value. A correctly filled Authorization
header looks as follows:
Authorization: Bearer eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCIsImN0eSI6IkpXVCJ9.eyJzdWIiOiJMb2dpblNhbXBsZSIsImVudCI6ImNsaWVudCIsImVpbiI6IjAxMjM0IiwiY2xpZW50aWQiOiIwMTIzNDU2IiwiYXpwIjoiMDEyMzQ1Njc4OWFiY2RlZjAxMjMiLCJhZ3JlZW1lbnRzIjoiQWdyZWVtZW50U2FtcGxlMSBBZ3JlZW1lbnRTYW1wbGUyIEFncmVlbWVudFNhbXBsZTMiLCJwb3J0Zm9saW9zIjoiUG9ydGZvbGlvU2FtcGxlMSBQb3J0Zm9saW9TYW1wbGUyIFBvcnRmb2xpb1NhbXBsZTMiLCJzY29wZSI6Ik9yZGVyc1JlYWQgT3JkZXJzQ3JlYXRlIFRyYWRlcyBQZXJzb25hbCBTdGF0cyIsImV4cCI6Mjg3MTc2MzE5OSwiaWF0IjowLCJpc3MiOiJBbG9yLklkZW50aXR5IiwiYXVkIjoiQ2xpZW50IFdBUlAgV2FycEFUQ29ubmVjdG9yIHN1YnNjcmlwdGlvbnNBcGkgQ29tbWFuZEFwaSBJbnN0cnVtZW50QXBpIFRyYWRpbmdWaWV3UGxhdGZvcm0ifQ.QOQVMIAoZ6SnF5urnIzJ0EvtQd9P5Sx355069kXoID207wHOTW0wkKNMcrIKXmENEQQ_0yDjqH_kjeqWLBJuqA
Connection
All requests to receive data via the WebSocket API, regardless of the data type, must be executed through the /ws
interface. Before sending a request, establish a WebSocket connection to this interface.
Full URL:
https://api.alor.ru/ws
https://apidev.alor.ru/ws
Authorization
Authorization is necessary to confirm that the sender has the rights to use the requested resource. Request authorization uses a JWT token, which acts as an Access token. A full description of available authorization methods is available in the Authorization section.
WebSocket API uses token
parameter to pass a token, which must be passed with each request that is executed.
Establish connection with the needed system environment and send a request to the required resource with a valid Access token as the value of the token
parameter:
{
"token": "eyJhbGciOiJ..."
}
If the request is correct, the server will return a message with code 200 confirming that the request was successfully processed:
{
"message": "Handled successfully",
"httpCode": 200,
"requestGuid": "d3c886f1-ea1e-4634-aff4-119c902ad926"
}
After that, the same WebSocket connection will start receiving messages with code 100 containing the requested information.
Identification
Request identification is necessary to specify belonging of returned messages to a specific subscription. Identifier must be provided by the user and passed in the message body as a value of the guid
parameter. Make sure that your software supports this function.
Any character combination can be used as a request identifier, including the wildcard characters !@##;%:?*()-_=+/|''
. Identifier has two restrictions:
Identifier value must be unique for used WebSocket connection. If the value has been previously used for another subscription, instead of combining several subscriptions, the old one will be replaced by a new one
Wildcard characters that violate the integrity of a JSON object must be escaped
Thus, the system will accept both Dxxxxx-Order-Market-No-812643-@-MOEX
and d3c886f1-ea1e-4634-aff4-119c902ad926
as the request identifier, provided that these values have not been previously passed under this WebSocket connection.
Properly filled guid
parameter does not require any additional prefixes and looks as follows:
{
"guid": "d3c886f1-ea1e-4634-aff4-119c902ad926"
}
Connection
All data requests to the GraphQL API must be made through the hyperion
interface. You can also find there the API schema, according to which requests should be constructed and processed.
https://api.alor.ru/hyperion
https://apidev.alor.ru/hyperion
Authorization
Authorization is necessary to confirm that the sender has the rights to use the requested resource. Request authorization uses a JWT token, which acts as an Access token. A full description of available authorization methods is available in the Authorization section.
GraphQL API uses the Authorization
header parameter to pass the token. The header must be passed with each executed request.
This token should be passed as a Bearer token, so the header must contain the Bearer
prefix before the passed value. A correctly filled Authorization
header looks as follows:
Authorization: Bearer eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCIsImN0eSI6IkpXVCJ9.eyJzdWIiOiJMb2dpblNhbXBsZSIsImVudCI6ImNsaWVudCIsImVpbiI6IjAxMjM0IiwiY2xpZW50aWQiOiIwMTIzNDU2IiwiYXpwIjoiMDEyMzQ1Njc4OWFiY2RlZjAxMjMiLCJhZ3JlZW1lbnRzIjoiQWdyZWVtZW50U2FtcGxlMSBBZ3JlZW1lbnRTYW1wbGUyIEFncmVlbWVudFNhbXBsZTMiLCJwb3J0Zm9saW9zIjoiUG9ydGZvbGlvU2FtcGxlMSBQb3J0Zm9saW9TYW1wbGUyIFBvcnRmb2xpb1NhbXBsZTMiLCJzY29wZSI6Ik9yZGVyc1JlYWQgT3JkZXJzQ3JlYXRlIFRyYWRlcyBQZXJzb25hbCBTdGF0cyIsImV4cCI6Mjg3MTc2MzE5OSwiaWF0IjowLCJpc3MiOiJBbG9yLklkZW50aXR5IiwiYXVkIjoiQ2xpZW50IFdBUlAgV2FycEFUQ29ubmVjdG9yIHN1YnNjcmlwdGlvbnNBcGkgQ29tbWFuZEFwaSBJbnN0cnVtZW50QXBpIFRyYWRpbmdWaWV3UGxhdGZvcm0ifQ.QOQVMIAoZ6SnF5urnIzJ0EvtQd9P5Sx355069kXoID207wHOTW0wkKNMcrIKXmENEQQ_0yDjqH_kjeqWLBJuqA
Sending requests
To demonstrate the syntax of the data retrieval request, we will use the order book request available in both the HTTP API and WebSocket API.
GraphQL API scheme is under development and some data may be unavailable. This includes order book data, so to demonstrate this method we use an example of obtaining basic instrument information.
- HTTP API
- WebSocket API
- GraphQL API
Interactive description of the request is available on the Order Book page
Request execution requires authorization.
To get the instrument order book via HTTP API, use the GET request to the endpoint /md/v2/orderbooks/{exchange}/{symbol}
, where:
Path parameters
Possible values: [MOEX
, SPBX
]
Exchange
Security code (Ticker)
Optional Query parameters can be added to fine-tune the query:
Query parameters
Possible values: >= 1
and <= 50
Order Book depth. The standard value is 20 (20x20) and maximum value is 50 (50x50).
20
Possible values: [Simple
, Slim
, Heavy
]
Representation format of returned data: Simple, Slim, Heavy
Filled with the required parameter values, the request looks like the following:
https://api.alor.ru/md/v2/orderbooks/MOEX/SBER?depth=5&format=Simple
https://apidev.alor.ru/md/v2/orderbooks/MOEX/SBER?depth=5&format=Simple
If the request is successful, the API will return a response with code 200 and a message containing the requested information:
{
"snapshot": true,
"bids": [
{
"price": 281.98,
"volume": 36
}
],
"asks": [
{
"price": 281.99,
"volume": 11
}
],
"timestamp": 1713387004,
"ms_timestamp": 1713387004878,
"depth": 20,
"existing": true
}
If the request processing ended with an error, the API will return information about the cause.
Complete list of all parameters and possible responses is available on the request description page.
Interactive description of the request is available on the Order Book page
Request execution requires authorization.
To get the instrument order book via WebSocket API, send a message with the value “opcode”: “OrderBookGetAndSubscribe”
and all subscription attributes to the authorized connection:
{
// Operation code for creating a subscription to the order book:
"opcode": "OrderBookGetAndSubscribe",
// Request Id:
"guid": "c328fcf1-e495-408a-a0ed-e20f95d6b813",
// Access token:
"token": "eyJhbGciOiJ...",
// Subscription attributes:
"code": "SBER",
"depth": 10,
"exchange": "MOEX",
"format": "Simple",
"frequency": 0
}
If the request is successful, the API will return a message with response code 200 confirming that the subscription has been created:
{
"message": "Handled successfully",
"httpCode": 200,
"requestGuid": "c328fcf1-e495-408a-a0ed-e20f95d6b813"
}
Then the connection will start receiving messages with code 100 containing the requested information:
{
"data": {
"snapshot": true,
"bids": [
{
"price": 257.7,
"volume": 157
}
],
"asks": [
{
"price": 257.71,
"volume": 288
}
],
"timestamp": 1702631123,
"ms_timestamp": 1702631123780,
"existing": true
},
"guid": "c328fcf1-e495-408a-a0ed-e20f95d6b813"
}
If the request processing ended with an error, the API will return information about the cause of this error.
Complete list of all parameters and possible responses is available on the request description page.
Schema with all supported parameters is available in the https://api.alor.ru/hyperion web interface.
Authorization for this request is not necessary, but acceptable.
GraphQL API has the advantage over other interfaces that you can request only the data you need through it, discarding all unnecessary parameters.
To get data via GraphQL API, establish a connection to the interface and compose the body of the request using schema.
Depending on the selected tool, the convenience of request creation may vary: when Postman, having access to the schema, allows to form requests by selecting parameters from a list, various “sandboxes” and most libraries expect the user to be able to read schemas and create requests manually. We recommend using Postman for the first time.
Request body consists of three parts: query type, fields and arguments to them. Currently ALOR Broker API supports only query
type, so set it at the root of the request.
query {
}
Fields are the parameters of the resource to which the request is addressed. They are used to create a path to the values from the system database that should be returned in the response. Set the instrument
field from the schema as the initial path value.
query {
instrument {
}
}
This field has required arguments that must be filled in for successful request processing. Field arguments must be provided in parentheses next to the field name itself. The following arguments are required for this request:
Arguments
MOEX
- Moscow ExchangeSPBX
- SPB Exchange
Security code (Ticker)
Possible values: [MOEX
, SPBX
]
Exchange code:
Trading mode code (Board)
query {
instrument(symbol: "SBER", exchange: "MOEX", board: "TQBR") {
}
}
The message does not yet contain fields for which parameters will be returned from the database. According to the scheme, the basicInformation
field is nested in the instrument
field, and the fields for which values will be returned from the database are nested in it:
Nested fields
MOEX
- Moscow ExchangeSPBX
- SPB Exchange
Security code (Ticker)
Possible values: [MOEX
, SPBX
]
Exchange code:
Short description of security
Short name of security
Security type
Add nested fields to the request, keeping the structure intact.
query {
instrument(symbol: "SBER", exchange: "MOEX", board: "TQBR") {
basicInformation {
symbol
exchange
description
shortName
type
}
}
}
If the message is well-formed and values for the specified fields exist in the database, they will be returned in the API response.
{
"data": {
"instrument": {
"basicInformation": {
"symbol": "SBER",
"exchange": "MOEX",
"description": "Sberbank",
"shortName": "Sberbank",
"type": "CS"
}
}
}
}
Один запрос может содержать несколько полей с одним именем одновременно. Чтобы упростить парсинг получаемых ответов, полям можно присвоить псевдонимы, которыми они будут подписаны в теле ответа. Например, добавьте всем полям, для которых возвращаются значения, префикс basic
:
query {
instrument(symbol: "SBER", exchange: "MOEX", board: "TQBR") {
basicInformation {
basicSymbol: symbol
basicExchange: exchange
basicDescription: description
basicShortName: shortName
basicType: type
}
}
}
In This will return the values under aliases instead of the original field names from the schema:
{
"data": {
"instrument": {
"basicInformation": {
"basicSymbol": "SBER",
"basicExchange": "MOEX",
"basicDescription": "Sberbank",
"basicShortName": "Sberbank",
"basicType": "CS"
}
}
}
}
If necessary, the request can be significantly modified: useless (for your task) fields can be removed when new fields, variables and fragments can be added to the request body. All depends on the task and capabilities provided by the current realization of GraphQL API
.
More information about GraphQL requests is available in the GraphQL API section.
What's next?
Additionally, we recommend reading the following related articles:
- Guide for Order management
- Guide for HTTP API
- Guide for WebSocket API
- Guide for GraphQL API
- Frequently asked questions
- Quick Start Guide for Production environment
- Quick Start Guide for Test environment