Маркетолог скопировал Production URL в исходящий вебхук Bitrix24, а workflow в n8n ещё не активировал - «Listen for test» молчит. Потом активировал, но в теле «пусто»: ждал JSON, а Bitrix прислал form-urlencoded. Повесил Telegram и ИИ до ответа - лиды «пропадали» на всплеске. За один вечер вы поднимете маршрут «новый лид -> сигнал в n8n -> полный лид в CRM-обработке» с быстрым ACK и проверкой токена.
Это не обзор всех интеграций Bitrix24 и не OAuth-приложение. Один маршрут для владельца малого бизнеса или ops, который уже крутит n8n (как в гайде по настройке webhook в n8n), но боится REST-приложений. Важно: Webhook - адрес сигнала «событие случилось», без полной анкеты. Итог вечера - лид в Executions, не «пустой» workflow.
Свежий факт из официальных docs Bitrix24 (июль 2026): у event handler нет retries. Если n8n не ответил или вернул ошибку, событие не перешлют. В блогах часто пишут «Bitrix ретраит» - опирайтесь на apidocs, а не на чужой опыт. Медленный ответ ещё и снижает приоритет handler в очереди. Не стоит вешать AI до ACK: сначала 200, потом тяжёлое - так вы получите стабильный приём.
Разведите входящий и исходящий вебхук - это две разные двери
Боль: путают «входящий» и «исходящий» и тратят вечер на мёртвую связку. Решение: запомните направление.
| Тип в Bitrix24 | Кто кого зовёт | Зачем в этом гайде |
|---|---|---|
| Исходящий вебхук | Bitrix -> n8n | Сигнал ONCRMLEADADD: «создали лид, вот ID» |
| Входящий вебхук | n8n -> Bitrix REST | Догрузка: crm.lead.get по ID (TITLE, телефон, UTM) |
| REST-приложение + OAuth | Сложная установка | Не нужно для вечернего маршрута лида |
На практике исходящий даёт только сигнал. Полный лид вы сами забираете входящим. Если на портале demo исходящий не работает; на коробке (on-prem) нужна активная лицензия - иначе не ждите POST. Избегайте демо-портала - лучше сразу портал с лицензией.
Поднимите Webhook в n8n с ответом сразу, не после Telegram
Боль: workflow крутит AI и чаты, пока Bitrix ждёт ответ - очередь душит handler, события теряются. Решение: Response Mode = Immediately (или Using «Respond to Webhook» сразу после триггера).
- Создайте workflow, добавьте узел Webhook.
- Method: POST. Path, например, bitrix-lead-add.
- Respond: Immediately (или Respond to Webhook node с кодом 200 сразу после Webhook).
- Скопируйте Test URL для первого прогона.
- Не включайте Raw Body: Bitrix шлёт application/x-www-form-urlencoded, n8n сам разложит поля.
Схема вечера:
Bitrix ONCRMLEADADD -> n8n Webhook (ACK сразу) -> проверка application_token -> HTTP crm.lead.get (входящий вебхук) -> Set TITLE/PHONE -> опционально Telegram менеджеру
Типичная ошибка: Respond = «When Last Node Finishes» и длинная цепочка до ответа. Для Bitrix это опасно именно из-за официального «No retries». В community n8n советуют early respond + idempotency при ретраях - у Bitrix ретраев нет, ACK критичен сильнее: второго шанса не будет. Убедитесь: Respond = Immediately, иначе handler молчит на всплеске.
Создайте исходящий вебхук на ONCRMLEADADD и сохраните токен
Боль: Handler URL вставлен не туда, событие не то, токен потеряли. Решение: один event - OnCrmLeadAdd / ONCRMLEADADD.
- В Bitrix24: Приложения -> Разработчикам -> Другое -> Исходящий вебхук (EN: Developer resources -> Other -> Outgoing webhook).
- Выберите событие создания лида: OnCrmLeadAdd / ONCRMLEADADD.
- В Handler URL вставьте Test URL из n8n (пока workflow в режиме Listen for test).
- Сохраните и скопируйте Application Token - он генерируется автоматически.
- Токен положите в Credentials / переменную n8n, не в публичный чат.
В реальном проекте маркетолог сначала вставил Production URL при выключенном workflow - Bitrix стучал в никуда. Рекомендуем Listen + Test URL, проверьте Executions, затем Activate и Production URL. Не делайте прод URL вслепую.
Прочитайте form-urlencoded и сверьте application_token до CRM-логики
Боль: в n8n «пустое тело», ищут JSON; либо любой POST с улицы запускает workflow. Решение: читайте поля event, data.FIELDS.ID, auth.application_token.
По docs Event Handler content-type событий - application/x-www-form-urlencoded. ONCRMLEADADD почти не шлёт полный объект лида: в основном ID в data.FIELDS.ID плюс блок auth. Исходящий webhook request не содержит user OAuth tokens - это не «вход от имени менеджера», а сигнал портала.
- Listen for test -> создайте тестовый лид в Bitrix24.
- В Executions откройте item: должны быть event=ONCRMLEADADD и ID лида.
- Добавьте IF или Code: auth.application_token равен токену из карточки исходящего вебхука.
- Если токен чужой - остановите ветку (и при кастомном Respond to Webhook отдайте 403 до бизнес-логики).
- Повторите ручной POST с левым токеном: workflow не должен идти в crm.lead.get.
Ключ токена может быть auth.application_token или вложенным form-полем - смотрите ключи в первом execution, не копируйте чужой скрин.
Рекомендация безопасности из Bitrix: сверяйте application_token (и при необходимости member_id) до любой записи в CRM, таблицу или Telegram. Публичный URL без проверки - дырка. Советуем резать чужой токен до crm.lead.get - так вы сможете закрыть дыру до прода.
Догрузите лид входящим вебхуком crm.lead.get и отдайте менеджеру
Боль: сигнала мало - нет телефона, TITLE, источника. Решение: второй вебхук (входящий) с правом CRM и HTTP Request.
- В Bitrix создайте входящий вебхук с правом на CRM (секрет уже в URL - не светите его в открытых репозиториях).
- В n8n после проверки токена добавьте HTTP Request: метод входящего вебхука crm.lead.get, ID из data.FIELDS.ID.
- Set/Code: замапьте TITLE, PHONE, SOURCE_ID / UTM, если есть в ответе.
- Опционально: Telegram или Slack менеджеру с именем и телефоном - это хвост, не ядро (отдельный гайд про бота не обязателен).
- Для критичных воронок заложите nightly reconciliation: crm.lead.list за сутки, сравнить с логами n8n - компенсация официального no retries.
Community-ноды вроде gustavojosemelo/n8n-nodes-bitrix24 тоже умеют ONCRMLEADADD. Для вечера хватит Webhook + HTTP. Делайте простой стек, не AmoCRM-OAuth. Результат - TITLE и телефон после get.
Пройдите чек-лист: тестовый лид, Production URL, чужой токен
Боль: на тесте всё зелёное, на проде тишина или дыра в безопасности. Решение: жёсткий чек-лист перед продакшеном.
Success criteria - вы на финише, если:
- Создан тестовый лид в Bitrix24 -> в n8n Executions есть success с event=ONCRMLEADADD и ID лида.
- IF/Code сверил auth.application_token с токеном из карточки исходящего вебхука.
- HTTP через входящий вебхук вернул TITLE и телефон.
- Ответ Bitrix ушёл быстро (Immediately или ранний Respond to Webhook).
- Повторный ручной POST с чужим токеном отклонён до crm.lead.get.
Fail-лист (часто ломается): неверный токен; workflow не Activate; в Bitrix всё ещё Test URL; включён Raw Body; Respond = Last Node без ACK; demo-портал без outbound; долгий AI до ответа.
- Activate workflow в n8n.
- В Bitrix замените Handler URL на Production URL.
- Создайте ещё один тестовый лид.
- Проверьте Executions: success, ID, TITLE после get.
- Сохраните скрин/лог первого продового успеха в свою wiki.
Что дальше: закрепите переменные токенов в Credentials; добавьте ветку fail -> алерт ops; при росте лидов - очередь на стороне n8n и сверка crm.lead.list. Чек-лист зелёный - маршрут готово: запустите ещё тестовый лид. Нужен разбор воронки под ваш стек - на calmopsai.com. Базовый приём webhook без Bitrix - в статье про n8n Webhook.
Материал проверен: эксперт Алексей Доронин (автоматизация бизнеса и ИИ).
Достоверность данных: факты по исходящему/входящему вебхуку, ONCRMLEADADD, form-urlencoded, application_token и официальному «No retries» сверены с apidocs Bitrix24 и docs.n8n.io на 28 июля 2026. Объёмы Wordstat в этом прогоне не верифицированы (API недоступен) - частотности не выдумывались.
Частые вопросы
Чем исходящий вебхук Bitrix24 отличается от входящего?
Исходящий: Bitrix сам стучит в ваш n8n URL при событии (например ONCRMLEADADD) и почти всегда шлёт только ID. Входящий: вы из n8n вызываете REST Bitrix (crm.lead.get и другие методы) по секретному URL. Для полного лида нужны оба.
Почему лиды «пропадают», если n8n отвечает медленно?
В официальных docs указано: retries нет. Ошибка или таймаут handler = событие не повторят. Плюс медленный ответ снижает приоритет в очереди. Ставьте Immediately / ранний Respond to Webhook, тяжёлое - после ACK.
Почему в n8n нет привычного JSON от Bitrix?
События идут как application/x-www-form-urlencoded. Не ждите красивого JSON body и не включайте Raw Body без нужды. Смотрите разобранные поля event, data.FIELDS.ID, auth.application_token в Executions.
Нужен ли self-hosted n8n ради персональных данных?
Если политика компании запрещает слать телефоны лидов во внешний SaaS - да, self-hosted (свой сервер) проще контролировать. Технически связка Webhook + HTTP работает и в n8n Cloud; выбор - про compliance, не про «обязательный Docker».
Можно ли обойтись без входящего вебхука?
Только если вас устраивает один ID без TITLE и телефона. На практике для алерта менеджеру и CRM-логики почти всегда нужен crm.lead.get через входящий вебхук или community-ноду с тем же REST.
Как создать вебхук в Bitrix24 для теста с n8n?
Приложения -> Разработчикам -> Исходящий вебхук -> событие OnCrmLeadAdd -> Handler = Test URL n8n -> Listen for test -> тестовый лид. После успеха Activate workflow и подставьте Production URL.
Bitrix24 шлёт дубли из-за ретраев?
Официально - нет: «No retries». Дубли чаще от двойного создания лида, повторного ручного POST или путаницы Test/Production. Для других систем с ретраями в n8n community советуют early respond + idempotency; для Bitrix главный риск - потеря события, а не flood повторов.