REST API шлюз для Битрикс24: кеширование, batch и управление токенами

Прокси-слой для Битрикс24: API-шлюз с кешированием и batch

Мы часто видим одну и ту же проблему: мобильное приложение, внешний сайт и ERP-система одновременно пытаются работать с REST API Битрикс24. Каждый клиент хранит свои токены, каждый должен знать специфику методов и обходить лимиты. Это неудобно, небезопасно и замедляет разработку. API-шлюз (gateway) — это промежуточный слой, который мы проектируем под ваш проект. Он стандартизирует взаимодействие: клиентские приложения обращаются к шлюзу с простым интерфейсом, а шлюз транслирует вызовы в Битрикс24, агрегирует данные и возвращает нормализованный ответ. Оценим ваш проект за один день — просто свяжитесь с нами.

Зачем нужен API-шлюз для Битрикс24?

Сокрытие сложности Битрикс24 API. Получение сделки со всеми связанными данными (контакт, компания, товары, задачи, дела) — это 5–7 отдельных REST-запросов к разным методам. Шлюз делает один вызов /deals/123, собирает все данные параллельно и отдаёт клиенту единый JSON.

Управление токенами. Клиентские приложения не хранят токены Битрикс24. Шлюз — единственное место, где хранятся OAuth-токены, обновляются access_token через refresh_token и контролируется их ротация.

Обход лимитов. Облачный Битрикс24 ограничивает: 2 запроса в секунду, 50 операций в batch. Шлюз реализует очередь и rate limiting — клиенты отправляют запросы сколько угодно быстро, шлюз сглаживает нагрузку. Прямая интеграция требует расчёта лимитов на стороне клиента, а шлюз берёт это на себя.

Почему API-шлюз снижает затраты на разработку?

Вместо того чтобы каждая команда клиентов разбиралась с особенностями REST API Битрикс24, шлюз предоставляет единый, документированный интерфейс. Разработчики тратят меньше времени на интеграцию и больше — на бизнес-логику. На практике это сокращает время вывода новых функций на 30%.

Архитектура и аутентификация шлюза

Шлюз — отдельный HTTP-сервис, как правило PHP (Laravel/Slim) или Node.js. Располагается между клиентами и Битрикс24.

Клиенты (мобильное приложение, внешний сайт, ERP) ↓ HTTP/JSON (собственный API шлюза) API-шлюз ├── Аутентификация клиента (JWT / API Key) ├── Валидация входных данных ├── Rate limiter ├── Кеш (Redis) ├── Маппер запросов → Битрикс24 REST └── Batch-агрегатор ↓ OAuth2 Token Битрикс24 REST API 

Аутентификация через API Key

Простейший вариант для server-to-server. Клиент передаёт ключ в заголовке X-API-Key. Шлюз проверяет ключ в своей БД, определяет привязанный Битрикс24-аккаунт и права.

Аутентификация через JWT

Для клиентов с пользователями. Пользователь логинится (через Битрикс24 OAuth или собственную систему), шлюз выдаёт JWT-токен. Каждый запрос к шлюзу содержит JWT в заголовке Authorization: Bearer. Шлюз декодирует токен, определяет пользователя и действует от его имени в Битрикс24.

Аутентификация через OAuth 2.0

Если шлюз обслуживает несколько клиентских приложений от разных организаций, строим полноценный OAuth-сервер (Authorization Code Flow). Каждый клиент-приложение — отдельный OAuth-клиент шлюза.

Как кеширование и batch ускоряют работу?

Два уровня кеша:

Ключ кеша: b24:{portal_id}:{method}:{hash(params)}. При webhook-событии ONCRMDEALUPDATE с ID=123 — инвалидируем b24:portal1:crm.deal.get:hash({id:123}). За счёт кеширования время ответа снижается в 5 раз по сравнению с прямыми запросами.

Битрикс24 поддерживает batch: до 50 методов в одном HTTP-запросе. Шлюз агрегирует параллельные вызовы клиента в batch. Согласно официальной документации REST API Битрикс24, это радикально сокращает количество HTTP-соединений. Пример batch-запроса:

// Клиент вызывает 3 ресурса шлюза "одновременно" // Шлюз собирает их в один batch к Битрикс24: $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": "Сделка с компанией Рога и Копыта", "amount": 50000.00, "stage": "negotiation", "contact": { "id": 456, "name": "Иван Петров", "phone": "+79001234567" } }