Limits

The limits on request intensity and resource consumption described in this section apply to the cloud version of Bitrix24. On-premise installations can independently manage the load generated by REST requests through their own server settings.

The restrictions on the REST API in the cloud version are implemented to regulate overall load—ensuring that a specific Bitrix24, which inefficiently uses automation resources, does not create problems for other users of the service.

Request Intensity Limits

The limit on request intensity to Bitrix24 is implemented based on the Leaky Bucket Algorithm. This allows applications to temporarily make requests very intensively while preventing them from doing so continuously.

Here's how it works:

  1. Each incoming request from an application increases a conditional "request counter" on the Bitrix24 side.
  2. Once the "counter" value exceeds the threshold value X, each subsequent incoming request is blocked. The application receives a status 503 with the error code QUERY_LIMIT_EXCEEDED in response.
  3. Simultaneously, the counter value automatically decreases by Y every second.

From the logic of this mechanism, two conclusions can be drawn:

  1. If your application makes no more than Y requests per second, it will never encounter the QUERY_LIMIT_EXCEEDED error.
  2. If the nature of your application requires making many requests temporarily, this is possible. There is no restriction stating "you cannot make more than Y requests per second." You can make a significant number of requests per second, just not continuously. For example, this occurs in integrations with telephony when several incoming calls happen simultaneously for reasons beyond the application's control.

The threshold values X and Y mentioned above depend on the tariff plan.

Tariff

Counter Decrease Rate,
Y

Limit Before Blocking,
X

Enterprise

5 per sec

250

Others

2 per sec

50

Important Features

It is important to know that request intensity is tracked separately for each Bitrix24 account. In other words, if your application uses REST too intensively on one account and hits the limits, it will not affect the application's operation on another account. This means that users on different accounts can use your solutions with varying intensity, allowing you to make the application logic quite flexible.

On the other hand, Bitrix24 only considers the IP address from which the REST request is made. In other words, if your server hosts several applications that all work with the same Bitrix24, the request intensity limit will be shared among all applications. Keep this feature in mind when designing.

What to Do If You Need to Make Many Requests?

In fact, the REST API limits in Bitrix24 are quite lenient for products of its class. Even making 2 requests per second allows for 172,800 requests per day on the account. As you may have understood from the description of the limitation mechanism, Bitrix24 allows for more requests.

Moreover, request does not equal record.

In particular, to retrieve data from Bitrix24, you can almost always use list methods *.list, which return 50 records per request. In other words, with the same minimal intensity of 2 requests per second, you can retrieve 8,640,000 leads or deals from Bitrix24 in a day.

Additionally, the Bitrix24 REST API has a batch method that allows you to execute 50 requests in one hit. The counter will increase by one, while the application effectively performs 50 different REST requests.

Using batch, where 50 requests to list methods *.list are executed sequentially, allows you to retrieve 2,500 records from Bitrix24 in one hit (50 requests with 50 records each). With this approach, you can obtain 432,000,000 records in a day.

Of course, it should be noted that besides request intensity, resource consumption limits also come into play in such cases, and in practice, you are unlikely to be able to retrieve such volumes of data in such a short time. Overall, REST as an approach is not designed for such mass and intensive data exchange. This is why a completely different mechanism is used in Bitrix24 for the built-in BI connector, which is intended for obtaining large data sets.

Nevertheless, combining batch with list methods and properly accounting for request intensity successfully addresses the overwhelming majority of tasks faced by developers.

Resource Consumption Limits

In the cloud version of Bitrix24, all REST request responses include an array time with additional information about the request execution time, which now has an additional key operating that indicates the execution time for a specific method.

For example:

{
            ...
            "time": {
                "start": 1712132792.910734,
                "finish": 1712132793.530359,
                "duration": 0.6196250915527344,
                "processing": 0.032338857650756836,
                "date_start": "2024-04-03T10:26:32+02:00",
                "date_finish": "2024-04-03T10:26:33+02:00",
                "operating_reset_at": 1705765533,
                "operating": 3.3076241016387939
            }
        }
        

The execution time data for each individual method is summed.

Triggering Limits

If the total execution time for requests exceeds 480 seconds within a 10-minute period, this method is blocked for all applications and webhooks of that account. All other methods continue to operate.

The key operating_reset_at returns the time in timestamp format when a portion of the limit for that method will be released.

The described metrics are calculated within Bitrix24 and depend on a number of interdependent factors: the volume of data in the account, the intensity of user interactions with the account, and other applications, etc.

The same request on different accounts can yield different operating values simply because, on one account, Bitrix24 has to process 10 records to get a result, while on another, it has to process 10,000 records. In other words, the resource consumption of your request is unpredictable on the application side.

However, there are a number of recommendations that you can follow to reduce the risks of triggering resource consumption limits.