Интеграция 1С-Битрикс с CRM Битрикс24
Типичная точка боли: интернет-магазин на 1С-Битрикс принимает заказы, а отдел продаж работает в Битрикс24 CRM. Менеджеры вручную переносят данные между системами — теряют заказы, дублируют контакты, не видят историю клиента. Готовое решение — REST API + вебхуки между двумя продуктами одного вендора, но настроить его правильно сложнее, чем кажется.
Архитектура связки
Битрикс24 предоставляет REST API через OAuth 2.0 или входящие вебхуки. 1С-Битрикс общается с ним через модуль bitrix24connector (если установлен) или напрямую через \Bitrix\Main\Web\HttpClient.
Ключевые методы REST, задействованные в интеграции:
| Метод Битрикс24 | Назначение |
|---|---|
crm.lead.add |
Создание лида из формы сайта |
crm.contact.add / crm.contact.update |
Создание/обновление контакта |
crm.deal.add / crm.deal.update |
Создание/обновление сделки из заказа |
crm.deal.productrows.set |
Привязка товарных позиций к сделке |
crm.company.add |
Создание компании (для B2B) |
crm.activity.add |
Добавление активности (звонок, письмо) |
Двусторонняя синхронизация: где возникают конфликты
Односторонняя передача (сайт → CRM) реализуется быстро. Проблемы начинаются при двусторонней: менеджер меняет статус сделки в Битрикс24 → сайт должен обновить статус заказа. Одновременно клиент на сайте может изменить заказ → CRM должна обновить сделку.
Кейс. Интернет-магазин стройматериалов, 200–300 заказов в сутки. После запуска двусторонней синхронизации через 3 дня выяснилось: статусы заказов «гуляют» — заказ, оплаченный на сайте, возвращался в статус «новый» из CRM. Причина: вебхук из Битрикс24 приходил позже события на сайте, перезаписывал статус без проверки приоритета.
Решение — поле-источник правды (source_system) в маппинге статусов:
// При получении вебхука из Б24 — проверяем метку времени
$localOrder = CSaleOrder::GetByID($orderId);
$localUpdated = strtotime($localOrder['DATE_UPDATE']);
$b24Updated = strtotime($webhook['data']['FIELDS']['DATE_MODIFY']);
if ($b24Updated > $localUpdated) {
// Обновляем заказ на сайте
CSaleOrder::StatusOrder($orderId, $newStatus);
}
Маппинг статусов
Статусы заказов в 1С-Битрикс хранятся в b_sale_status, статусы сделок Битрикс24 — в стадиях воронки (crm.status.list). Маппинг — не взаимно однозначный: в Битрикс24 может быть 10 стадий, на сайте — 5 статусов. Создаём таблицу соответствия, которая хранится в пользовательской таблице или в настройках модуля.
| Статус заказа (сайт) | Стадия сделки (Б24) |
|---|---|
| N (новый) | NEW |
| P (оплачен) | WON |
| F (доставлен) | WON |
| C (отменён) | LOSE |
| D (доставляется) | EXECUTING |
Синхронизация товарного каталога
Если в Битрикс24 используется каталог (crm.product.*), важно синхронизировать его с каталогом сайта. Иначе в сделке будут «ручные» позиции без привязки к номенклатуре. Метод crm.deal.productrows.set принимает массив позиций с PRODUCT_ID — ID товара в каталоге Битрикс24.
Стратегия: при создании товара на сайте через событие OnAfterIBlockElementAdd автоматически создаём/обновляем запись в Битрикс24 через crm.product.add. XML_ID хранится как внешний идентификатор для дедупликации.
Обработка ошибок и очередь
REST API Битрикс24 имеет rate limit: 2 запроса в секунду на облачный тариф. При всплеске заказов прямой синхронный вызов упрётся в лимит. Правильная архитектура — очередь:
- Событие на сайте (
OnSaleOrderSaved) помещает задачу в таблицу очереди. - Агент Битрикса каждые 30 секунд обрабатывает очередь порциями по 2 запроса/сек.
- При ошибке запись остаётся в очереди с увеличенным счётчиком попыток (max 5).
| Этап интеграции | Трудозатраты |
|---|---|
| Настройка OAuth / вебхуков | 2–4 ч |
| Маппинг полей и статусов | 4–6 ч |
| Разработка обработчиков событий | 8–12 ч |
| Реализация очереди и обработки ошибок | 6–10 ч |
| Двусторонняя синхронизация статусов | 6–10 ч |
| Тестирование и отладка | 8–12 ч |







