Skip to main content

Frequently asked questions

tip

Question is not on the list or the information seems incomplete? Contact us at Telegram!

General questions​

Is the API available to everyone?

First of all, the API is intended for ALOR Broker clients, therefore requests to it require authorization on behalf of a certain trading account. If you are not a client yet, we can provide you with access to the Test Environment of the system, where you can test the capabilities of the API in a simulation environment. In addition, some requests to the Production environment of the system can be executed without authorization, but in response the system will return information that was up to date 15 minutes ago.

I see transactions on my behalf that I have not made. What's going on?

The most likely that your authorization tokens become available to the third parties. In this case, we recommend to:

  • Revoke all previously created Refresh tokens to terminate current access to the trading system

  • Change the password from the developer account to prevent third parties from accessing the creation and reading of new tokens

  • Change your password from your ALOR Broker client account to prevent your trading account from being linked to a third-party developer account.

We also recommend you to improve your own security of sensitive data to prevent re-leakage.

Third parties have accessed my tokens. What do I do?

The authorization mechanism provides the possibility to revoke tokens that have been compromised or lost their use. However, only the Refresh token can be revoked. If an Access token has been compromised, the Refresh token used for its creation must be revoked to block it. If it is not clear which token has been compromised, we recommend revoking all tokens and creating new tokens after taking measures to improve the security of sensitive data.

Authorization​

How can requests be authorized?

Authorization is always performed using Access tokens passed in the header or body of the request. There are two main options for obtaining these tokens:

  • Manual Token Retrieval: An option intended for users who interact with the API directly. In this case, you manually issue a Refresh token in the Developer Account and use it to manually refresh the Access token used in requests

  • OAuth 2.0: An option designed for connecting third-party applications. When authorizing, the user is redirected from the application to ALOR's OAuth service, where he/she authorizes under his/her own data. This data will not be passed to the application. Instead, in case of successful authorization, the application receives an auth code, which is used to request tokens without the user's participation

How many tokens can be created at one time?

The system does not limit the number of Refresh and Access tokens active simultaneously. Nevertheless, when using the authorization system, it is recommended to be guided by the concept of fair use of the system and avoid actions that may negatively affect the system performance.

For example, if you perform multiple API operations every second, you should not request a new Access token for each one. Instead, we recommend using a single token that is updated a few minutes before it expires.

What is the lifespan of the tokens? Are they perpetual?

For security reasons, the lifetime of tokens is limited and depends on the system environment and how it is obtained:

Token

Environment

Obtaining option

Lifespan

Refresh

Production

Manually

1 year

Through OAuth service

1 month

Test

Manually

Through OAuth service

N/A

Access

Any

Any

30 minutes

How to configure API access rights for tokens?

When authorizing requests using the JWT mechanism, there is no possibility to configure access rights - the token holder always has full access to the system API.

You can restrict access rights only for applications connected to the OAuth 2.0 authorization service.

System environments​

What system environments are available?

In the ALOR Broker trading system users have access to two operational environments:

  • Production is the system environment that provides access to real exchange data and uses real portfolios and positions in them. This environment is designed to work with exchanges and make real trades.

  • Test is a system environment that uses simulation data and gaming portfolios in its work. The purpose of this environment is to provide users with a platform for testing API requests and applications based on them.

How do I get access to the environment I need?

To get access to the Production environment, you have to be a client of the ALOR Broker trading system and be able to obtain authorization tokens. The Quick Start Guide for the Production environment can help you with this.

The Test environment also has a Quick Start Guide. The difference is that you do not need to be a client of the broker to work with this environment, it is enough to ask for a test trading account, on behalf of which the requests will be authorized.

I can't place an order in the test environment, although trading on the exchange is open. What's the problem?

Test environment works on its own trading schedule, which may differ from the exchange's current schedule. In addition, some functions of the test environment may be unavailable due to ongoing work. Please repeat the request later.

Yesterday I've traded a lot in the test environment, and today all my orders and trades have disappeared! What's going on?

That's the way it should be.

Test environment is a simulation environment designed for testing APIs. When a new trading day starts, all previous results are canceled, giving the opportunity to continue the tests.

HTTP API​

Can I use the HTTP API without authorization?

Some requests can be executed without authorization, but their priority in processing will be lower compared to authorized requests. In addition, in response to an unauthorized request, the server returns data that was up to date 15 minutes ago.

How many requests can be completed in one minute?

There are no certain limits on the number of simultaneously executed requests on the system side.

However, when sending requests, you should take into account the concept of fair use and avoid actions that may cause damage to the trading system or affect other Broker's clients. Such actions include, but are not limited to:

  • Frequent (several times per second) execution of requests for large amounts of data

  • Frequent (several times per second) execution of duplicate requests of the same type

  • Transmission of obviously meaningless data to the system or messages with broken syntax, causing errors in processing of received requests

caution

In case of detecting signs of unfair use, the Broker has the right to temporarily suspend the processing of requests from the user committing objectionable actions until the circumstances are clarified and the reasons for such actions are eliminated.

WebSocket API​

Can I use the WebSocket API without authorization?

No. All requests made to the WebSocket API must be authorized. If you are unable or unwilling to use a trading account with real portfolios and positions, you can request a test trading account to access the Test environment.

How do I authorize requests to the WebSocket API?

As with HTTP API requests, WebSocket requests are authorized by passing the actual Access token to the system. The method of transmission depends on the interface used:

  • For the /ws interface, the Access token must be passed in every request sent as the value of the token parameter in the message body

  • For the /cws interface, authorization takes a separate request with the authorize operation code and Access token as the value of the token parameter in the message body

So, for the /ws interface authorization should be made for each request separately, while for the /cws interface the connection itself is authorized, making all further requests also authorized.

Authorization validity period

For security reasons, the lifespan of an Access token is limited to 30 minutes from the moment of creation. Once this time expires, any request using an expired token will be considered unauthorized. The same applies to requests made via the /cws interface — after the token expires, the connection remains active, but is no longer considered authorized. To re-authorize the connection, repeat the request with the authorize operation code and a new Access token.

How many connections can be online at the same time?

There are no specific limits on the number of simultaneously active connections on the system side.

However, when creating new connections, you should keep in mind the concept of fair use and avoid actions that may disrupt the trading system or affect other Broker's clients. For fair use reasons, it is recommended to limit the number of connections to the following values:

  • Up to 10 connections for managing stock information subscriptions

  • Up to 1 connection for managing orders

caution

In case of detecting signs of unfair use, the Broker has the right to temporarily suspend the processing of requests from the user committing objectionable actions until the circumstances are clarified and the reasons for such actions are eliminated.

How many subscriptions can be created within one connection? One connection means one subscription?

The system does not have any specific limits on the number of subscriptions that can be active within one connection.

However, it should be taken into account that API limits the size of the unprocessed messages buffer to 5000 records for each connection. When the software that has established a connection with the trading system fails to process the received messages and the buffer overflows, the connection will be terminated by the system and the user will be temporarily (from several minutes up to two hours) blocked from creating new subscriptions.

We recommend you to ensure that the software you use provides mechanisms for reconnecting, re-subscribing and promptly recording incoming messages in its own storage before passing them to further processing.

What happens to subscriptions when a connection is terminated? Will they be restored after creating a new connection?

If the connection is terminated, all subscriptions set within it will be canceled and you will have to restore them manually.

Is it possible to transfer a subscription from one connection to another?

Depends on what is meant by transfer.

Each WebSocket connection is a separate data exchange session isolated from other similar ones. For one WebSocket connection there are no subscriptions existing within other similar connections.

So, if we are talking about creating a similar subscription in a new connection, this is possible. If we are talking about transferring a subscription from one connection to another (automatic cancelation of a subscription in the old connection and creation of a subscription with the same parameters in the new connection), then this scenario is not provided by the API and must be implemented in the client software.