Bitrix24 API Rate Limiting Setup
Integration works, data syncs — then on Friday evening, script starts sending requests in a loop without pauses, hits limit, gets QUERY_LIMIT_EXCEEDED error and crashes. Or worse — doesn't crash but immediately retries request, making situation worse. Bitrix24 API has strict rate limits, and any integration must account for them. Otherwise — data loss, desynchronization, application blocking.
Bitrix24 REST API Limits
Bitrix24 applies restrictions at two levels:
| Type | Limit | Comment |
|---|---|---|
| Webhooks (incoming) | 2 requests per second | Per one webhook |
| Server apps (OAuth) | 2 requests per second | Per app per portal |
| Daily limit | 10,000 requests per day | For free tiers. Commercial tiers higher |
| batch request | 50 commands per batch | Counts as 1 API request |
When exceeding limit, API returns HTTP 503 with body {"error":"QUERY_LIMIT_EXCEEDED"}. Retry recommended after 500 ms — but not immediately.
Daily limit resets at 00:00 portal time. For marketplace apps, limits differ and depend on developer subscription.
batch Method
batch — 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 within batch execute sequentially. Can use results of previous commands via $result:
cmd[0]=crm.deal.get?id=123
cmd[1]=crm.contact.get?id=$result[0][CONTACT_ID]
Instead of 50 separate requests (25 seconds at 2 req/sec) — one request in 1-2 seconds.
Rate Limit Strategies
Exponential backoff — on receiving QUERY_LIMIT_EXCEEDED, retry with increasing delay: 500 ms → 1 s → 2 s → 4 s. Maximum 5 attempts, then — error to log.
Request queue — instead of direct API calls, requests queued (Redis, RabbitMQ, DB). Worker processes queue, respecting 500 ms interval between requests. Excludes situation where two processes simultaneously send requests exceeding combined limit.
Token bucket — software counter: application tracks request count over last second and blocks sending until slot freed. Implemented via shared state (Redis) for distributed systems.
Time-based distribution — heavy syncs (full deal export, catalog update) run at night when users don't work with API.
Spending Monitoring
Current API call spending can be checked via app.info method — returns remaining requests for current period. For webhooks, no analogous metric — must count on your side.
B24 logs (section Settings → Event Log) record API errors, including limit exceedance. Recommend setting up monitoring: alert when 80% daily limit reached.
What We Configure
- Integration architecture accounting for rate limits: batch requests, queues, backoff
- Worker for sequential API request processing with speed control
- Transition from single requests to batch for bulk operations
- Monitoring API limit spending and alerts on approaching threshold
- Load distribution: background syncs in off-peak hours
- Diagnosis and elimination of
QUERY_LIMIT_EXCEEDEDerrors