We often encounter this scenario: the integration is working, data is syncing — then on Friday evening a script starts sending requests in an endless loop, hits the limit, gets a QUERY_LIMIT_EXCEEDED error, and crashes. Or worse — it doesn't crash but immediately retries, making the situation worse. Bitrix24 API has strict rate limits, and any integration must account for them. Otherwise — data loss, desynchronization, application blocking. Our experience shows: proper rate-limiting configuration saves hours of debugging and prevents incidents. Our team has 10+ years of development experience on Bitrix24 and has implemented over 50 integrations, so we know all the pitfalls. This article covers Bitrix24 REST API limits, optimization methods, and specific scenarios we implement for clients. You will learn how to avoid typical mistakes and build a resilient integration.
Bitrix24 API limits overview
Bitrix24 applies limits at two levels:
| Type | Limit | Comment |
|---|---|---|
| Webhooks (incoming) | 2 requests per second | Per webhook |
| Server applications (OAuth) | 2 requests per second | Per application per portal |
| Daily limit | 10,000 requests per day | For free plans. Commercial — higher |
| batch request | 50 commands per batch | Counts as 1 API request |
According to Bitrix24 REST API documentation, the per-second limit is 2 requests. When the limit is exceeded, the API returns HTTP 503 with body {"error":"QUERY_LIMIT_EXCEEDED"}. Retry is recommended after 500ms — not immediately. The daily limit resets at 00:00 portal time. For marketplace applications, limits differ and depend on the developer subscription.
Using batch method to bypass limits
batch is the main tool for saving requests. One batch call contains up to 50 commands and counts as one request:
POST https://your-domain.bitrix24.by/rest/batch/ cmd[0]=crm.deal.list?filter[STAGE_ID]=WON cmd[1]=crm.deal.list?filter[STAGE_ID]=LOSE cmd[2]=crm.contact.list?filter[TYPE_ID]=CLIENT Commands inside a batch run sequentially. You can use the results of previous commands via $result:
cmd[0]=crm.deal.get?id=123 cmd[1]=crm.contact.get?id=$result[0][CONTACT_ID] Using batch requests is 50 times more efficient than individual calls. Instead of 50 separate requests (25 seconds at 2 req/sec) — one request in 1-2 seconds.
What is the best rate limiting strategy for your integration?
Comparison of limit management strategies helps you choose the right approach. Batch requests are 50 times more efficient than individual calls and the most impactful optimization.
| Strategy | Complexity | Reliability | Applicability |
|---|---|---|---|
| Exponential backoff | Low | Medium | Simple scenarios |
| Request queue | Medium | High | High-load |
| Token bucket | High | High | Distributed systems |
Exponential backoff — when receiving QUERY_LIMIT_EXCEEDED, retry with increasing delay: 500ms → 1s → 2s → 4s. Maximum 5 attempts, then log error.
Request queue — instead of direct API calls, requests are placed in a queue (Redis, RabbitMQ, DB). A worker processes the queue, respecting the 500ms interval between requests. This eliminates the situation where two processes simultaneously send requests and collectively exceed the limit.
Token bucket — a software counter: the application tracks the number of requests in the last second and blocks sending until a slot is free. Implemented via shared state (Redis) for distributed systems.
Also use time separation: heavy synchronizations (full deal export, catalog update) run at night when users are not using the API.
Choosing a limit management strategy
Strategy choice depends on load and architecture. For simple scenarios, exponential backoff is sufficient — it requires no additional services. If the integration is high-load (more than 10 requests per second total), use a request queue on Redis — it guarantees compliance even with concurrent requests. Token bucket fits distributed systems where multiple microservices access one portal.
How to check current API usage?
Current API call usage can be checked with the `app.info` method — it returns the number of remaining requests for the current period. For webhooks, there is no similar metric — you need to count on your side. In the B24 logs (Settings → Event Log), API errors including limit exceedances are recorded. We set an alert at 80% of the daily limit.Avoiding QUERY_LIMIT_EXCEEDED
Implementing proper rate limiting in Bitrix24 helps avoid QUERY_LIMIT_EXCEEDED errors and optimizes API limits usage. Avoiding these errors can save an estimated $2,000 per incident in lost productivity and debugging time.
Step-by-Step Implementation Guide
- Analyze your integration's request pattern.
- Group operations into batch requests using the
batchmethod. - Implement exponential backoff retry logic with a maximum of 5 attempts.
- Set up monitoring and alerts at 80% of daily limit.
- Conduct load testing to verify compliance.
What's included in our integration optimization work
- Integration architecture considering rate limits: batch requests, queues, backoff
- Worker for sequential API request processing with speed control
- Migration from single requests to batch for bulk operations
- Monitoring of API limit usage and alerts when approaching thresholds
- Load distribution: background synchronizations during non-peak hours
- Diagnostics and fixing
QUERY_LIMIT_EXCEEDEDerrors - Documentation of the configured integration
- Access to monitoring dashboards and training for your team
- Configuration of webhooks and OAuth application limits
- Performance testing and optimization report
Project evaluation is free. If you encounter QUERY_LIMIT_EXCEEDED errors or want to optimize your API integration, contact us. Our certified specialists have many years of experience with Bitrix24 and guarantee the stability of your integrations. Get a consultation — we'll help eliminate bottlenecks and prevent downtime.