How Do You Fix the Bitrix24 QUERY_LIMIT_EXCEEDED Error?

The Bitrix24 error QUERY_LIMIT_EXCEEDED arrives as an HTTP 503 with the message “Too many requests”. It means your integration sent requests faster than your Bitrix24 account allows. The fix is to lower the request rate to 2 per second or less (5 per second on Enterprise), retry with growing delays, pack calls into batches and stop parallel request streams from one IP address. Everything here comes from Bitrix24’s REST API documentation, checked on October 22, 2026.

What does the Bitrix24 QUERY_LIMIT_EXCEEDED error look like?

Bitrix24 reports errors as a JSON body with an error field and an error_description field. For this one the documented values are below.

Field	Value
HTTP status	503
Error code	QUERY_LIMIT_EXCEEDED
Message	Too many requests
Meaning	The request intensity limit has been exceeded
Official fix	Reduce the request intensity and retry the call later

Source: Bitrix24 REST API documentation, “Error codes”, checked Oct 22, 2026.

Bitrix24’s documentation says to recognise errors by the fields in the body, not by status alone, because errors inside a batch request come back with status 200. In a batch response, look in result.result_error.

Why does Bitrix24 return QUERY_LIMIT_EXCEEDED?

Bitrix24 uses a leaky bucket. Each request adds to a virtual counter, the counter drains every second, and when it is above the threshold the next request is blocked. The numbers depend on the plan.

Plan	Counter drains at (Y)	Blocks above (X)
Enterprise	5 per second	250
All other plans	2 per second	50

Source: Bitrix24 REST API documentation, “REST API limits”, checked Oct 22, 2026.

Two rules follow, and both are in the documentation. At no more than Y requests per second you will never see the error. Brief bursts above Y are fine, for example when several telephony calls arrive together, but you cannot sustain them. Limits are tracked separately for each Bitrix24 account, so a block in one account does not affect your app in another. Bitrix24 also notes that applications on the same server IP share a limit, which is why parallel jobs from one machine cause trouble.

The most common causes follow from this:

Symptom	Likely cause	Fix
Error appears during a bulk import or sync loop	One request per record, sent as fast as the loop runs	Use batch, add a short delay between requests
Error appears only when several jobs run at once	Parallel request series from one IP address	Run one series at a time, or queue them
Error appears in bursts, then clears	Burst above the drain rate, then the counter recovers	Retry with increasing delays
Error returns right after a retry	Retry fires immediately with no delay	Back off: 1, 2, 4 seconds and so on
Error on a webhook-driven integration with many events	Event volume spikes above 2 per second	Buffer events in a queue and drain at the allowed rate

How do you fix QUERY_LIMIT_EXCEEDED in Bitrix24?

Work through these in order. They come from the recommendations on Bitrix24’s limits page.

1. Slow the request rate. Keep the average at or below 2 requests per second (5 on Enterprise). A fixed delay of 500 ms between calls does it on standard plans.
2. Retry with increasing delays. When you get the 503, wait, retry, and lengthen the wait each time. Do not retry instantly.
3. Stop parallel request series from one IP address. Two scripts at 2 per second each is 4 per second against the same bucket.
4. Use the batch method. It accepts up to 50 method calls in one HTTP request, which reduces the HTTP requests that are counted. It does not remove the resource limits of the methods inside the batch.
5. Request less per call. Use pagination, ask only for the fields you need, and split big operations into smaller requests.
6. Move heavy work out of the request path. Put long-running jobs in an external queue or background process, and use the BI connector for large data pulls, which Bitrix24 says uses a different mechanism.

How much data can you pull at the Bitrix24 rate limit?

More than most people expect, if you page properly. Bitrix24’s own arithmetic on the limits page:

Method	Calculation	Result
Requests per day at 2 per second	2 x 86,400	About 172,800 requests
Records per day, *.list at 50 records per page	172,800 x 50	About 8.64 million records
Records per HTTP request with batch of 50 list calls	50 x 50	Up to 2,500 records

Source: Bitrix24 REST API documentation, “REST API limits”, checked Oct 22, 2026. These are the documentation’s upper-bound figures, not a promise of throughput.

The documentation is clear that the REST API is not designed for mass or intensive data exchange, so treat these as ceilings. For a one-time move of a CRM, the list-view export is simpler: see how to export Bitrix24 CRM to Excel. To compare this ceiling with other platforms, our CRM API rate limits comparison lists the same numbers for other CRMs.

How do you confirm it is a rate limit and not something else?

Check three things in the response and your own logs before you change any code.

1. The error code. QUERY_LIMIT_EXCEEDED with status 503 is a request-rate block. OPERATION_TIME_LIMIT with status 429 is a different block (see the next section). ACCESS_DENIED with status 401 and the text “REST is available only on commercial plans” means the account has no REST access at all, which is the case on the Free plan. See what the Bitrix24 Free plan includes.
2. Your own request count. Count the calls sent per second in your logs, across every script and webhook that uses the same account and IP address. If the sum is above 2, the cause is found.
3. Whether the block clears by itself. A rate block lifts as the counter drains. One that never lifts is not this error. OVERLOAD_LIMIT (401, “REST API is blocked due to overload”) is a manual block that Bitrix24 says is not lifted automatically, and the fix is to contact Bitrix24 technical support.

What is the difference between QUERY_LIMIT_EXCEEDED and OPERATION_TIME_LIMIT?

QUERY_LIMIT_EXCEEDED counts how often you call. OPERATION_TIME_LIMIT counts how long your calls run.

Bitrix24 tracks method execution time in ten one-minute baskets per application or webhook. When the total goes above the limit, calls to that method return HTTP 429 with the message “Method is blocked due to operation time limit”. Other methods, applications and webhooks keep working. The cloud limit is set by Bitrix24’s configuration. The documentation’s 480 seconds is an example, and the self-hosted default is 420 seconds when the limit is switched on.

The fix differs: pause calls to the blocked method, use operating_reset_at from the time block of your last successful response as the time for the first retry, and if it blocks again wait for the next basket reset. The operating value in the same time object shows how close you are, so log it.

Does the limit apply to self-hosted Bitrix24?

No. The documentation says request intensity and resource limits apply to the cloud version, and that in the self-hosted version the load is configured on the server side. Request execution time there depends on server settings.

When to get help

A rate limit is usually a symptom of an integration written as one call per record. If your sync is business-critical, or you are moving a large Bitrix24 database into a CRM with a bulk API, a specialist can design the queue, batching and retry logic once. Bitrix24 is quoted per project and aibrevo does not implement it. Migrating Bitrix24 data into Salesforce, HubSpot, Dynamics 365, Zoho CRM, Pipedrive, monday.com, Airtable or GoHighLevel is a common request, and the CRM integrations guide and CRM migration guide cover the groundwork. Book a short call or send a message, and see the Zoho CRM service page for one common destination.

Sources

• Bitrix24 REST API documentation, REST API limits, checked Oct 22, 2026.
• Bitrix24 REST API documentation, Error codes, checked Oct 22, 2026.