limits.md

REST API 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 instance, which inefficiently utilizes automation resources, does not create problems for other users of the service.

{% note tip "" %}

If you are developing integrations for Bitrix24 using AI tools (Codex, Claude Code, Cursor), connect to the MCP server so that the assistant can utilize the official REST documentation.

{% endnote %}

Request Intensity Limitations

The limit on request intensity to Bitrix24 is implemented based on the Leaky Bucket Algorithm. This allows applications to temporarily make requests at a very high rate while preventing constant high-intensity requests.

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 X, each subsequent incoming request is blocked. The application receives a 503 status 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 your application's specifics require making many requests in a short period, 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, but you won't be able to maintain that rate continuously. For example, this occurs in integrations with telephony systems when multiple incoming calls happen simultaneously for reasons beyond the application's control.

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

#| || Plan | Counter Decrease Rate, Y | Limit Before Blocking, X || || Enterprise | 5 per sec | 250 || || Others | 2 per sec | 50 || |#

{% note info "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 performance on another account. This means that users on different accounts can use your solutions with varying intensity, allowing you to make your 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 multiple applications that all work with the same Bitrix24 account, the request intensity limit will be shared among all applications. Keep this feature in mind when designing.

{% endnote %}

What to Do If You Need to Make Many Requests?

In fact, the REST API limits in Bitrix24 are quite lenient for products in 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.

Specifically, 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 minimum 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 includes a batch method that allows you to execute 50 requests in a single 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 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 large data retrieval.

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

Resource Consumption Limitations

In the cloud version of Bitrix24, all REST request responses include an array time with additional information about the request execution time, which now includes an additional key operating, indicating the execution time for the 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
    }
}

Data on the execution time of requests to each individual method is aggregated.

{% note info "Triggering Limits" %}

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

{% endnote %}

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

The described metrics are calculated within Bitrix24 and depend on a variety 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 may need to process 10 records to return a result, while on another, it may need 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.