Связываем Bitrix24 с внутренними системами, ERP, сайтом, складом и сервисами, для которых нет готового модуля.
API
Интеграция Битрикс24 через API
Проектируем обмен CRM с системой, которую нельзя подключить подходящим готовым решением. Описываем данные, права и обработку ошибок до написания кода.
REST APIвебхукизащита от дублейконтроль ошибок
REST · события · очередиBitrix24
без дублейповторное событие обновляет ту же запись
журналвидно, что не передалось и почему
праватолько необходимый доступ
События CRMBitrix24 → внешняя система
Операционные данныевнешняя система → Bitrix24
Справочникив одну или обе стороны
Срокпосле короткого разборасхема → тест → запуск
Передаём клиентуработающая интеграциякарта обмена, журнал ошибок и чек-лист проверки
Сценарий
Когда нужен собственный обмен
Готовый коннектор передаёт не те поля, не поддерживает нужное действие или не укладывается в правила компании. REST API Битрикс24 позволяет построить обмен вокруг конкретного сценария, если нужные методы и доступы доступны в вашем окружении.
Сначала проверяем возможность штатного подключения на странице интеграций Битрикс24. Собственную разработку выбираем там, где она решает описанное ограничение, а не ради самого факта использования API.
Повторная отправка одного события не должна создавать дубли — это закладываем в схему до разработки.
Ошибки не прячутся: у интеграции есть журнал, понятный статус и способ безопасно повторить неуспешную операцию.
Архитектура
Как проходит разработка
Собираем описание систем, примеры запросов и объектов. Сопоставляем поля и методы REST API Битрикс24 с ожидаемым действием сотрудника. После этого готовим ограниченный прототип и согласуем критерии приёмки.
Событие
Определяем, что запускает обмен: новая сделка, изменение статуса, форма или действие внешней системы.
Проверка
Проверяем права, обязательные поля и внешний идентификатор записи.
Передача
Отправляем только те данные, которые действительно нужны второй системе.
Ответ
Сохраняем результат и связываем записи между системами.
Контроль
Ошибку можно увидеть, понять и повторить без создания дубля.
Типовой сценарий: внешний сервис присылает статус заказа, обработчик находит сделку по внешнему номеру и обновляет согласованное поле. Неизвестный номер и повтор события обрабатываются по заранее выбранным правилам. Это пример возможной интеграции, а не описание клиентского проекта.
Как обеспечиваем устойчивость
При проектировании учитываем ограничения REST API, временную недоступность систем и повторные события. Фиксируем внешний идентификатор объекта, порядок повторной передачи и защиту от дублей. Если объём обмена требует очереди, она обрабатывает события отдельно от ответа пользователю.
СущностьОписаниеНаправлениеКонтроль
События CRMсоздание и обновление лидов, сделок и контактовBitrix24 → внешняя системаконтроль ошибок
Операционные данныестатусы, документы и сервисные действиявнешняя система → Bitrix24контроль ошибок
Справочникипользователи, категории, продукты и статусыв одну или обе стороныконтроль ошибок
Ошибки и повторыжурнал, безопасный повтор и уведомлениячерез промежуточный сервисконтроль ошибок
В журнале должен быть виден этап сбоя без раскрытия токенов и лишних данных клиента. Для сложного маршрута назначаем источник значений каждого поля: иначе две системы могут по очереди отменять изменения друг друга.
Кому подходит
- Есть собственная ERP или учётная система, склад, транспортная система, сервис-деск или внутреннее приложение.
- Нужен нестандартный маршрут данных, которого нет в готовых решениях.
- Важно видеть ошибки обмена и безопасно восстанавливать передачу данных.
Что используем
ИнструментыBitrix24 REST APIвебхукипромежуточный сервисочередь сообщениймониторинг и логи
01
Входящие и исходящие вебхуки
Вебхук
Входящий вебхук Битрикс24 позволяет внешнему обработчику вызывать доступные методы REST API. Его права зависят от сотрудника и выбранных разрешений. Секретный URL хранится на сервере; его нельзя помещать в открытый код формы или страницу сайта.
REST API
Исходящий вебхук Битрикс24 передаёт событие в ваш обработчик. Событие и получение полного состояния объекта — разные действия: при необходимости обработчик отдельно запрашивает данные. Проверяем подлинность входящего события и доступность обработчика.
Приложение
Вебхуки Битрикс24 подходят не каждому проекту. Когда требуется установка приложения, другой способ авторизации или дополнительные возможности, сравниваем варианты до разработки. Права выдаём под нужные действия, не под доступ ко всему порталу. Для собственного интерфейса или решения с отдельным жизненным циклом рассмотрите разработку приложения для Битрикс24.
02
Что добавляем перед рабочим запуском
✓
Ограничиваем нагрузку и сохраняем операции, которые нужно повторить после временного сбоя.
✓
Защищаем от дублей: повтор одного события обновляет ту же запись, а не создаёт новую.
✓
Ведём журнал ошибок с понятным объектом, временем и причиной.
✓
Храним ключи и токены только на сервере, а права ограничиваем нужными разделами.
✓
Добавляем уведомление, если обмен остановился и требует внимания.
03
Входящий вебхук Bitrix24: когда его достаточно
Для одного контролируемого портала и простой серверной автоматизации входящий вебхук часто быстрее полноценного приложения. Он подходит, когда нужно получить или изменить данные от имени заранее настроенного пользователя.
✓
Ключ вебхука хранится только на сервере и не попадает в JavaScript или публичный HTML.
✓
Права пользователя вебхука ограничиваем только нужными разделами.
✓
Все внешние записи связываем с CRM по устойчивому идентификатору, а не по названию.
✓
Если задача должна работать на многих порталах, отдельно оцениваем приложение и авторизацию.
04
Исходящие события: как получать изменения из CRM
Когда внешней системе нужно быстро узнавать об изменениях в Bitrix24, используем события там, где они доступны. Это лучше постоянного опроса API и уменьшает задержку между действием менеджера и обновлением второй системы.
05
Что проверяем перед сдачей интеграции
Повторное событие безопасно
Одинаковая операция не создаёт вторую сделку, контакт или заказ.
Сбой виден
Можно понять, какая запись не передалась и почему, не разбирая серверные файлы вслепую.
Нет лишних прав
Интеграция получает только тот доступ, который нужен конкретному сценарию.
Риски и внимание к деталям
Что проверяем и передаём
Проверяем успешную передачу, недостаточные права, неверные данные, повтор события, ограничение запросов и временный сбой. Передаём схему обмена, описание настроек и порядок диагностики. Для регулярных изменений подключаем техподдержку Битрикс24.
Если по полученному событию CRM должна назначить задачу или запустить согласование, отдельно описываем автоматизацию бизнес-процессов в Битрикс24. Стоимость разработки зависит от сценариев и требований к обмену; готовим оценку после их разбора.
!
Если не проектировать версии API и схему изменений, доработки быстро ломают старые сценарии.
!
Токены и доступы нельзя хранить в коде страницы или раздавать без сегментации прав.
!
Без очереди и повторов временная ошибка превращается в потерянное событие.
FAQ
Вопросы об API
Короткие ответы на вопросы, которые обычно появляются до оценки интеграции.
Где посмотреть документацию REST API Битрикс24?
В официальной документации REST API. На этой странице описан подход к проекту; справочник методов остаётся у разработчика платформы.
Достаточно создать вебхук, чтобы интеграция заработала?
Вебхук даёт способ доступа, но не задаёт сопоставление полей, обработку ошибок и правила работы с повтором. Эти части зависят от сценария.
Можно выполнять запросы без ограничений?
Нет. При проектировании учитываем актуальные ограничения выбранного окружения и способа подключения. Не обещаем неограниченный обмен или одинаковые возможности любого тарифа.
Разобраться глубже
Практические материалы по теме
Практические материалы о настройке, проверке и типовых ошибках до запуска.
Обсудим обмен через API
Опишите систему, нужные объекты и действие в CRM
