Bitrix24 API Gateway: Caching, Batch, Token Management

Bitrix24 API Gateway: Caching, Batch, Token Management

We often see the same issue: a mobile app, external site, and ERP system simultaneously working with the Bitrix24 REST API. Each client stores its own tokens, each must know the method specifics and bypass limits. This is inconvenient, insecure and slows down development. An API gateway is an intermediate layer we design for your project. It standardizes interaction: client applications call the gateway with a simple interface, and the gateway translates calls to Bitrix24, aggregates data, and returns a normalized response. Assess your project in one day — just get in touch with us.

Why Do You Need an API Gateway for Bitrix24?

Hiding Bitrix24 API complexity. Retrieving a deal with all related data (contact, company, products, tasks, activities) requires 5–7 separate REST calls to different methods. The gateway makes one call /deals/123, gathers all data in parallel, and returns a single JSON to the client.

Token management. Client applications do not store Bitrix24 tokens. The gateway is the single place where OAuth tokens are stored, access_token is refreshed via refresh_token, and rotation is controlled.

Bypassing limits. Cloud Bitrix24 restricts: 2 requests per second, 50 operations per batch. The gateway implements a queue and rate limiter — clients send requests as fast as they want, and the gateway smooths out the load. Direct integration requires calculating limits on the client side; the gateway takes this over.

Why Does an API Gateway Reduce Development Costs?

Instead of each client team learning the intricacies of the Bitrix24 REST API, the gateway provides a single, documented interface. Developers spend less time on integration and more on business logic. In practice, this reduces time-to-market for new features by 30%.

Gateway Architecture and Authentication

The gateway is a separate HTTP service, typically PHP (Laravel/Slim) or Node.js. It sits between clients and Bitrix24.

Clients (mobile app, external site, ERP) ↓ HTTP/JSON (gateway's own API) API Gateway ├── Client authentication (JWT / API Key) ├── Input validation ├── Rate limiter ├── Cache (Redis) ├── Request mapper → Bitrix24 REST └── Batch aggregator ↓ OAuth2 Token Bitrix24 REST API 

Authentication via API Key

Simplest for server-to-server. The client sends the key in the X-API-Key header. The gateway validates the key in its database, identifies the linked Bitrix24 account and permissions.

Authentication via JWT

For clients with users. The user logs in (via Bitrix24 OAuth or a custom system), the gateway issues a JWT token. Each request to the gateway carries the JWT in the Authorization: Bearer header. The gateway decodes the token, identifies the user, and acts on their behalf in Bitrix24.

Authentication via OAuth 2.0

If the gateway serves multiple client applications from different organizations, build a full OAuth server (Authorization Code Flow). Each client application is a separate OAuth client of the gateway.

How Caching and Batch Speed Up Performance

Two cache levels:

Cache key: b24:{portal_id}:{method}:{hash(params)}. On webhook event ONCRMDEALUPDATE with ID=123 — invalidate b24:portal1:crm.deal.get:hash({id:123}). Thanks to caching, response time drops 5x compared to direct requests.

Bitrix24 supports batch: up to 50 methods in one HTTP request. The gateway aggregates parallel client calls into a batch. According to official Bitrix24 REST API documentation, this drastically reduces HTTP connections. Example batch request:

// Client calls 3 gateway resources "simultaneously" // Gateway combines them into one batch to Bitrix24: $batch = [ 'deal' => 'crm.deal.get?id=123', 'contact' => 'crm.contact.get?id=456', 'products' => 'crm.deal.productrows.get?id=123', ]; $result = $b24->batch($batch); 

{ "id": 123, "title": "Deal with company ABC", "amount": 50000.00, "stage": "negotiation", "contact": { "id": 456, "name": "Ivan Petrov", "phone": "+79001234567" } }