Изменения в Битрикс24 — вебхуками в вашу систему
У Битрикс24 есть исходящие вебхуки, но они уходят один раз и без подписи: если ваш сервер в этот момент недоступен, изменение сделки теряется молча. HookPilot идёт с другой стороны: сам опрашивает REST портала по дате изменения, хранит найденное и доставляет в ваш бэкенд с повторами и ручным перезапуском.
Без карты можно проверить отправку через API в один эндпоинт. Для источника или подключения и получателя — Starter от 2 900 ₽/мес.
Как подключить
Одно подключение опрашивает один метод REST. Сделки, лиды и задачи заводятся отдельными подключениями.
- 1
Создайте на портале входящий вебхук: Разработчикам → Другое → Входящий вебхук. Отметьте право CRM, а для задач ещё и «Задачи». Портал выдаст адрес вида https://ваш-портал.bitrix24.ru/rest/1/код/.
- 2
Создайте в HookPilot подключение с коннектором «Опрос HTTP API (JSON)» и укажите адрес метода целиком: к выданному адресу припишите crm.deal.list и сортировку order[DATE_MODIFY]=ASC.
- 3
Заполните пути: список элементов лежит в result, идентификатор элемента в ID. Заголовок авторизации не нужен, код вебхука уже внутри адреса.
- 4
Настройте курсор: имя параметра filter[>DATE_MODIFY], значение берите из поля элемента DATE_MODIFY. Задайте тип события, например deal.updated, выберите расписание и подпишите эндпоинты.
Как устроен опрос
Код вебхука вместо токена
Авторизация Битрикс24 живёт прямо в адресе, отдельный заголовок не нужен. Поэтому адрес подключения — такой же секрет, как пароль: кто его знает, тот работает с порталом в рамках выданных прав.
Курсор по дате изменения
Курсор переставляется на DATE_MODIFY последнего доставленного элемента и уходит в фильтр следующего опроса. Сортировка order[DATE_MODIFY]=ASC обязательна: без неё курсор перескочит через часть изменений.
Страница в пятьдесят элементов
REST Битрикс24 отдаёт до пятидесяти записей за запрос. Хвост дочитывается следующим опросом по сдвинутому курсору, поэтому разовый всплеск изменений не теряется, а размазывается по расписанию.
Дедупликация по ID
Ключ дедупликации считается по ID элемента и дате изменения. Повторный опрос того же состояния сделки второго события не создаст.
Событие не пришло
Три причины, которые встречаются чаще остальных. Всё принятое видно в ленте принятого в кабинете вместе с типом и историей доставки.
Список всегда пуст
Чаще всего у вебхука не отмечено право CRM или в адресе потерян суффикс метода. Откройте адрес подключения в браузере: Битрикс24 ответит JSON, и сразу будет видно, приходит result или ошибка прав.
Одни и те же сделки приходят каждый опрос
Не задан путь до идентификатора или потеряна сортировка по DATE_MODIFY. Без сортировки курсор не двигается, и каждый опрос перечитывает одно и то же окно.
Изменения приходят с задержкой
Это шаг расписания: при опросе раз в пять минут событие появится в пределах пяти минут после правки в портале. Для более плотного потока уменьшите интервал, помня про лимиты REST портала.
Чем это лучше исходящих вебхуков самого Битрикс24?
Исходящий вебхук портала уходит один раз: не ответил ваш сервер — изменение потеряно, и узнать об этом неоткуда. Здесь событие сначала сохраняется у нас, потом доставляется с повторами до восьми раз, с историей попыток и ручным перезапуском в пределах срока хранения.
Можно ли следить за сделками и задачами одновременно?
Да, двумя подключениями: у них разные методы REST и разные пути до идентификатора. Эндпоинт-получатель при этом может быть один, достаточно подписать его на оба типа событий.
Что будет, если отозвать вебхук на портале?
Подключение перейдёт в ошибку, текст ответа портала будет виден в его состоянии. События при этом не теряются: как только адрес снова рабочий, опрос продолжится с сохранённого курсора.
Другие интеграции
Платёжные системы, маркетплейсы и любая система с подписанными вебхуками или HTTP API.