За n8n идут, когда CRM должна поговорить с тем, о чём она не знает: складской базой, внутренним сервисом, чужим API. И первый час уходит на вопрос, который инструкции обходят стороной, — готового узла «Битрикс24» на панели нет. Связка при этом собирается нормально, просто из общих кубиков, и ломается потом всегда в одних и тех же местах. Ниже — рабочая схема в обе стороны и то, что честнее не выносить наружу.

Есть ли готовый узел Битрикс24 в n8n?

Штатного нет. Страница Битрикс24 у самого n8n отправляет к узлу HTTP Request с обычной авторизацией — то есть вызывать REST API вы будете руками. Есть пакеты от сообщества, некоторые закрывают и CRM-сущности, и задачи, и телефонию, но их сопровождают третьи лица, за изменениями API они успевают не всегда, а на управляемых инстансах установка такого пакета — вопрос политики, а не одной кнопки. Для сценария на три-четыре метода узел HTTP Request выходит дешевле, чем аудит чужого кода: API — обычный JSON поверх HTTPS, и один узел закрывает любой метод.

Как n8n записывает данные в Битрикс24?

Через входящий вебхук. В портале он создаётся в разделе для разработчиков: отмечаете, какие права ему нужны, и получаете адрес вида https://<портал>/rest/<id-пользователя>/<токен>/<метод>.json — авторизация зашита в сам адрес, поэтому узлу HTTP Request не нужно ничего, кроме этой ссылки и аккуратности с ней. Название метода и параметры передаются ровно так, как описано в документации: crm.item.add, crm.item.update, tasks.task.add.

Дальнейшая судьба связки держится на двух свойствах этого адреса. Вебхук работает с правами сотрудника, который его создал, — сценарий, не видящий воронку, отвалится по правам при живом и верном токене; поэтому заводите вебхуки под служебной учёткой, а не под тем, кто в тот день оказался за компьютером. И токен не обновляется сам: он живёт, пока его не удалили или пока не уволили того сотрудника, — отсюда и удобство, и цена утечки. Механика входящих и исходящих разобрана в руководстве по вебхукам.

Как запустить сценарий n8n из Битрикс24?

Способа два, и ведут они себя по-разному. Исходящий вебхук портала подписывается на события — изменилась сделка, появился лид — и стучится на адрес узла Webhook. Срабатывает он на каждое подходящее событие, неважно, откуда пришло изменение: от человека, из импорта или от другой интеграции. Тело приходит в виде формы, а не JSON, поэтому на первом запуске узел показывает разобранные поля вместо привычного тела запроса.

Второй способ — позвать n8n из самого процесса. Робот «HTTP-запрос GET/POST» внутри бизнес-процесса дёргает адрес узла Webhook ровно в тот момент, который вы выбрали, и передаёт только то, что решили передать. «Сформировать JSON из полей» соберёт тело из значений процесса без ручного экранирования кавычек, а «Извлечь значение из JSON по пути» вернёт ответ n8n обратно в процесс — подробнее про разбор ответов в статье про JSON в бизнес-процессах. Там, где доставку терять нельзя — заказ ушёл в производство, документ отправлен на подпись, — ставьте «Отказоустойчивый вебхук»: он повторяет попытки по своему расписанию и сообщает, сколько их понадобилось, вместо того чтобы промолчать после первой неудачи.

Что дешевле оставить внутри портала?

То, что из портала и не выходит. Смена стадии, заполнение поля, постановка задачи, ветвление по условию: если гонять это через внешний сценарий, вы покупаете лишний круг по сети, второе место для отладки и квоту, за которой надо следить, — и больше ничего. Разумное деление простое: n8n отвечает за системы снаружи, портал — за свои же записи, а между ними один вызов. Цену такого выбора мы разбирали на примере коннекторов против роботов внутри портала, а сама внутренняя часть — обычная настройка роботов.

Почему сценарий молчит?

Сначала со стороны n8n: у узла Webhook два адреса, тестовый и рабочий, и рабочий отвечает только при включённом сценарии — собранная и проверенная в тестовом режиме связка замолкает ровно тогда, когда за ней перестают смотреть. Потом со стороны портала: исходящий вебхук, подписанный не на то событие или не на тот тип сущности, не породит ни одного запроса, и пустой список запусков в n8n — это про подписку, а не про сеть.

Если запросы доходят, но возвращают ошибку, читайте её текст, а не жмите «повторить»: права вебхука, неверный код поля и превышение лимита выглядят одинаково «не работает», но чинятся по-разному. Лимит стоит держать в голове отдельно — портал разрешает пару вызовов в секунду, и цикл на несколько сотен записей без пауз упирается в него сам. Когда же не сработал робот, из которого всё должно было начаться, помогает разбор, почему роботы не запускаются.

Что дальше

Разложите сценарий на два списка: шаги, которые трогают внешние системы, и шаги, которые трогают только записи портала. Второй список переносите внутрь — обычно после этого остаётся по одному вебхуку в каждую сторону, и поддерживать такую связку куда проще. Кубики для внутренней части лежат в каталоге роботов, а если нужного нет — опишите задачу: «Роботека» делает недостающие активити бесплатно и выкладывает в общую библиотеку.