Робот в CRM сработал, но ваша интеграция ничего не получила. Первая реакция — снова вызвать event.bind. Не спешите. Повторная привязка без проверки легко превращает «событие не пришло» в «каждое событие приходит дважды».
Разделите цепочку на четыре участка: регистрация обработчика, отправка со стороны Битрикс24, приём HTTPS-запроса и ваша бизнес-логика. Проверять их надо именно в этом порядке.
Шаг 1. Посмотрите фактические привязки
Вызовите event.get с авторизацией того же приложения, которое регистрировало событие. Пользователь и контекст имеют значение: обычный пользователь видит свои доступные обработчики.
curl -X POST -H "Content-Type: application/json" -H "Authorization: Bearer $B24_ACCESS_TOKEN" -d '{}' 'https://example.bitrix24.ru/rest/event.get'В ответе найдите точное имя события и handler. Проверьте домен, путь, протокол и хвостовой slash. PASS: одна ожидаемая привязка ведёт на текущий production URL. FAIL: привязки нет, их несколько или адрес остался от старого домена.
Шаг 2. Проверьте endpoint не с самого сервера
Битрикс24 обращается к handler извне. Проверка через loopback-адрес доказывает только работу приложения внутри хоста. Выполните запрос с другой сети или внешнего monitoring host.
curl -sS -o /dev/null -D - --max-time 10 https://hooks.example.ru/bitrix24/eventsОбработчик POST может вернуть 405 на GET, и это не всегда ошибка. Нас интересуют DNS, TLS, отсутствие 301 на другой домен, экран авторизации, блокировка WAF и долгий timeout. Финальный handler должен быть публичным HTTPS URL.
| Ответ | Что это обычно означает | Куда смотреть |
|---|---|---|
| 301/302 | URL не конечный | Nginx и канонический домен |
| 401/403 | Запрос остановила авторизация или WAF | Правила доступа и access log |
| 404 | Путь не совпал с маршрутом приложения | location и router |
| 500/502/504 | Ошибка приложения или upstream | error log и process manager |
Шаг 3. Создайте контрольное событие
- Запишите время с секундной точностью.
- Создайте тестовую сущность, которая вызывает нужное событие.
- Найдите POST в reverse-proxy access log.
- По request ID проследите очередь и обработчик.
# пример фильтра для Nginx access log
grep '10/Sep/2026:21:15' /var/log/nginx/access.log | grep '/bitrix24/events'Не публикуйте токен или полный payload в тикете. Достаточно времени, пути, HTTP-кода, request ID и имени события. Персональные поля маскируйте.
- PASS: POST виден, сервер быстро отвечает 2xx, событие один раз попадает в устойчивую очередь.
- FAIL: POST виден с 5xx — проблема уже на вашей стороне.
- FAIL: event.get показывает верный handler, но POST отсутствует — проверьте завершение установки приложения и контекст привязки.
Когда выполнять event.bind повторно
Только когда event.get доказал отсутствие нужной записи. Официальная документация отдельно указывает: после удаления или обновления приложения привязки нужно выставлять заново, а до завершения установки события не отправляются.
curl -X POST -H "Content-Type: application/json" -H "Authorization: Bearer $B24_ACCESS_TOKEN" -d '{"event":"ONCRMLEADADD","handler":"https://hooks.example.ru/bitrix24/events"}' 'https://example.bitrix24.ru/rest/event.bind'Имя события в примере замените на реально нужное и сверьте его с документацией. После bind снова вызовите event.get. Не считайте ответ метода единственным доказательством: контрольное CRM-действие всё равно нужно.
Частые ошибки
Проверять не тем токеном. Привязка принадлежит контексту приложения, а диагностика выполняется другим пользователем.
Лечить потерю повторным bind. В итоге один lead создаёт две задачи во внешней системе.
Отвечать 200 до фиксации. Процесс упал после ответа, а собственного журнала события нет.
Пускать тяжёлую логику в HTTP handler. Медленные запросы к 1С и AI лучше вынести в очередь после устойчивой записи входящего события.
Чек-лист
- event.get показывает одну ожидаемую привязку.
- Handler указывает на конечный HTTPS URL.
- DNS и TLS доступны извне.
- WAF не требует интерактивной авторизации.
- Access log содержит контрольный POST.
- У события есть request ID и защита от повторной обработки.
Сделайте приём события коротким
HTTP handler не должен ждать тяжёлый обмен с 1С, генерацию документа или ответ AI. Его задача — проверить базовую форму запроса, присвоить внутренний event ID, записать payload в устойчивое хранилище и вернуть контролируемый ответ. Бизнес-обработка идёт worker-процессом.
В журнале храните время приёма, имя события, ID портала, хеш payload, HTTP-результат и число попыток обработки. Токены из поля auth маскируйте. Если очередь недоступна, не отвечайте успешным кодом до надёжной записи: иначе событие потеряется между reverse proxy и приложением.
Как проверить защиту от повторов
Отправьте сохранённый тестовый payload дважды. PASS: журнал видит две доставки, но бизнес-эффект создаётся один. FAIL: каждая доставка создаёт новую задачу или повторно запускает обмен. Ключ идемпотентности формируйте из стабильных полей события и целевой операции, а не из времени приёма.
Что делать, если не помогло
Соберите один диагностический пакет: JSON из event.get без токена, время контрольного изменения, итоговый URL, HTTP-код и строки access/error log. Если POST не дошёл, граница перед endpoint. Если дошёл и получил 2xx, проверяйте очередь и idempotency. Для выбора механизма прочитайте разницу REST и webhook, а ограничения запросов разберите по инструкции о QUERY_LIMIT_EXCEEDED. CTR1 может проверить интеграцию Битрикс24 от привязки до бизнес-эффекта.
