Разработка вебхуков для Битрикс24
Сделка переходит в статус «Оплачено» — через несколько секунд в учётной системе появляется счёт, в логистической платформе создаётся заявка на доставку, клиенту уходит SMS. Без вебхуков это была бы ручная работа или polling-цикл с проверкой изменений каждую минуту. Вебхуки — это push-уведомления от Битрикс24 о событиях в системе. Мы, как разработчики с 5+ летним опытом, гарантируем надёжную реализацию таких сценариев.
В среднем на один портал приходит 50-100 событий в минуту в пике. Обработка каждого в реальном времени критична для бизнес-процессов. Без правильно настроенной системы вебхуков компании сталкиваются с задержками в доставке заказов, дублированием счетов и потерей данных. Мы решаем эту проблему с помощью проверенных архитектурных паттернов и стека Битрикс24.
Какие проблемы решают вебхуки для Битрикс24?
Вебхуки автоматизируют реакцию на события без участия человека. Основные бизнес-задачи:
- Синхронизация сделок CRM с учётной системой (1С, ERP)
- Автоматическое создание заказов в логистике (СДЭК, Почта России)
- Отправка уведомлений клиентам (SMS, email, Telegram)
- Обновление данных в аналитических дашбордах
Из практики: на одном из проектов интеграция с 1С требовала обработки 200 событий в минуту. Мы реализовали асинхронную обработку через RabbitMQ и добились времени обработки менее 1 секунды. Это в 10 раз быстрее, чем периодический опрос (polling), который давал задержку 30-60 секунд.
Входящие и исходящие вебхуки: в чём разница?
В Битрикс24 два типа вебхуков, которые часто путают:
| Тип | Направление | Аутентификация | Пример использования |
|---|---|---|---|
| Исходящий (Outbound) | Битрикс24 → Ваш сервер | OAuth или токен в теле | Реакция на событие CRM |
| Входящий (Inbound) | Внешняя система → Битрикс24 | Токен в URL | Простая интеграция без OAuth |
Исходящие вебхуки настраиваются через интерфейс или REST API event.bind. Входящие вебхуки — это URL с встроенным токеном, которые можно использовать для вызова REST API Битрикс24 без полноценного OAuth-потока. Выбор типа зависит от сценария: исходящие — для реакции на события, входящие — для внешнего управления из сторонних систем.
Как настроить обработчик вебхука?
Пошаговый процесс настройки обработчика:
- Зарегистрируйте подписку через
event.bindс указанием события и URL обработчика. - Реализуйте endpoint, который принимает POST-запросы от Битрикс24.
- Верифицируйте подпись (проверьте токен авторизации и IP-адрес).
- Передайте данные в асинхронный обработчик (через очередь).
- Верните HTTP 200 OK как можно быстрее.
Пример подписки на изменение стадии сделки:
$client->call('event.bind', [ 'event' => 'ONCRMDEALSTAGEID', 'handler' => 'https://integration.mycompany.ru/b24/webhook/deal-stage', 'auth_type' => 1, 'options' => [ 'add_auth' => 'Y', ], ]); Полный список доступных событий CRM включает более 150 наименований: ONCRMDEALCHANGE, ONCRMCONTACTCHANGE, ONCRMLEADCHANGE и другие. Ознакомиться с перечнем можно в официальной документации REST API.
Почему важна идемпотентность?
Обработчик вебхука должен отвечать быстро (до 5 секунд) и обрабатывать данные асинхронно. Если ответ медленный или не 200 OK — Битрикс24 повторяет запрос с экспоненциальным backoff. Без идемпотентности повторная обработка создаст дубли: например, двойной счёт или два заказа на доставку. Идемпотентность гарантирует, что повторные вызовы не приведут к побочным эффектам.
public function handleDealStage(Request $request): Response { if (!$this->verifySignature($request)) { return response('Unauthorized', 401); } DealStageChangedJob::dispatch($request->all())->onQueue('b24-events'); return response('OK', 200); } class DealStageChangedJob implements ShouldQueue { public function handle(): void { $dealId = $this->data['data']['FIELDS_AFTER']['ID']; $stageId = $this->data['data']['FIELDS_AFTER']['STAGE_ID']; // Проверка идемпотентности: событие уже обработано? if ($this->alreadyProcessed($dealId, $this->data['event_id'])) { return; } if ($stageId === 'WON') { $this->accountingService->createInvoice($dealId); $this->logisticsService->createShipment($dealId); $this->smsService->sendPaymentConfirmation($dealId); } } } Как обеспечить надёжность системы?
Верификация подписи.
Битрикс24 может передавать токен авторизации (auth[access_token]). Обработчик проверяет, что токен принадлежит ожидаемому порталу. Для дополнительной защиты добавляем IP-whitelist — список IP Битрикс24 публикуется в официальной документации.
Хранение и мониторинг.
Все входящие вебхуки логируются в таблице vendor_b24_webhook_log:
- время получения
- тип события
- тело запроса (с маскированием токенов)
- статус обработки (pending / processed / failed)
- количество попыток
Dashboard мониторинга показывает: очередь необработанных событий, события с ошибками, среднее время обработки. При накоплении более 50 необработанных событий — алерт на email или Telegram администратору.
Паттерн replay.
При сбое внешней системы (например, учётная система недоступна) часть вебхуков может не обработаться. Модуль реализует повторную обработку: администратор выбирает диапазон дат и тип события, система заново выполняет обработчик для всех событий из лога.
Что входит в работу
При заказе разработки вебхуков вы получаете:
- Карту событий: анализ бизнес-процессов и привязка к событиям Битрикс24
- Разработку обработчиков (endpoint + асинхронная очередь)
- Настройку логирования и мониторинга
- Документацию по развёртыванию и эксплуатации
- Обучение администраторов (1 час)
- Техническую поддержку в течение 1 месяца после сдачи
Сроки и стоимость
| Масштаб | Состав | Срок | Стоимость |
|---|---|---|---|
| Базовый | 2–3 типа событий + очередь + логирование | 2–3 недели | Индивидуально |
| Средний | + верификация + мониторинг + replay + несколько систем | 4–6 недель | Индивидуально |
| Расширенный | + оркестрация сложных сценариев + SLA-контроль | 7–10 недель | Индивидуально |
Перед разработкой составляем карту событий: какое событие Битрикс24 -> какое действие во внешней системе. Это позволяет оценить объём работы и выявить потенциальные конфликты.
Типичные ошибки при разработке вебхуков
- Отсутствие идемпотентности → дублирование данных
- Синхронная обработка → таймауты и повторные запросы
- Игнорирование верификации подписи → уязвимость для поддельных запросов
- Недостаточное логирование → сложно отлаживать сбои
Вебхуки — эффективный инструмент для интеграции, работающий в реальном времени и не требующий polling. Они сравнимы с паттерном Webhook.
Свяжитесь с нами для оценки вашего проекта — мы предложим оптимальное решение под ключ. Опыт 5+ лет и более 50 успешных интеграций гарантируют качество. Закажите разработку вебхуков и получите готовое решение за 2–3 недели.