Бот мессенджера MAX связывается с n8n через вебхук: платформа MAX отправляет события на HTTPS-адрес узла Webhook, а ответы клиентам уходят запросами к API MAX из узла HTTP Request. Среди встроенных узлов в документации n8n на 5 октября 2026 отдельного узла MAX нет, поэтому схема строится на двух универсальных узлах. Такой вариант подходит для приёма заявок, когда оператор подтверждает ответ вручную; свободный диалог без проверки человеком собирать рано.
Связь MAX и n8n
Событие из MAX приходит в n8n как обычный вебхук с JSON, а ответ клиенту отправляется запросом POST к адресу platform-api2.max.ru с токеном бота в заголовке Authorization.
Условный пример: сервисная компания обслуживает кофемашины для офисов. Клиент пишет боту в MAX: «Течёт бак, нужен выезд». Сценарий должен принять сообщение, понять, что это заявка, записать её, показать оператору и после его подтверждения ответить клиенту. Получение событий, запись и подтверждение полностью укладываются в узлы n8n; остаётся лишь самостоятельно оформить подключение.
Бота в MAX создают для подтверждённой организации, ИП или самозанятого, токен выдаётся в настройках бота. Токен передаётся только в заголовке Authorization, передача через параметры адреса отключена. Храните его в хранилище доступов n8n как учётные данные с заголовком и вставки в узлы избегайте.
Перед работой над сценарием выясните, кто в компании владеет ботом и его токеном. Бот создаётся под профиль организации, ИП или самозанятого, поэтому доступ к токену оформляется на роль, и личный аккаунт сотрудника в этой цепочке лишний. Тогда уход человека из компании оставляет приём заявок рабочим.
Тот же приём заявки на другой платформе разобран в материале про заявку из Telegram в n8n. Здесь механика входа иная: триггера для MAX среди встроенных узлов n8n нет, и подписку на события вы оформляете сами.
Подписка на события
Документация MAX рекомендует вебхук для рабочей среды, а длинный опрос оставляет для разработки: он ограничен по скорости и для рабочей среды непригоден. Оба режима вместе включить нельзя. Подписка создаётся запросом POST на адрес /subscriptions с тремя полями.
| Поле | Что задаёт | Особенности |
|---|---|---|
| url | Адрес вашего вебхука | Только HTTPS, порт 443, сертификат доверенного центра или Минцифры, имя в сертификате совпадает с доменом |
| update_types | Какие события присылать | Например, message_created и bot_started; лишние типы исключайте |
| secret | Строка для проверки отправителя | От 5 до 256 символов: латиница, цифры, дефис; приходит в заголовке X-Max-Bot-Api-Secret |
- Опубликуйте сценарий с узлом Webhook и скопируйте рабочий адрес. Тестовый адрес работает лишь пока редактор ждёт тестовое событие, и для подписки непригоден.
- Включите в узле проверку заголовка и впишите секрет из будущей подписки в учётные данные Header Auth.
- Отправьте узлом HTTP Request запрос на создание подписки с токеном в заголовке Authorization и тремя полями выше.
- Напишите боту тестовое сообщение и найдите запуск во вкладке Executions.
Требования к адресу строгие: самоподписанные сертификаты отвергаются, а приём вебхуков по HTTP прекращён. Если перед n8n стоит веб-сервер с шифрованием, сверьте, что он отдаёт полную цепочку сертификатов. Сетевые детали размещения собраны в статье про локальную установку n8n.
Приём и проверка
Узел Webhook должен вернуть код 200 в течение 30 секунд, иначе MAX засчитает доставку неудачной. Платформа повторяет отправку до десяти раз с нарастающей паузой, а если в течение восьми часов успешного ответа нет, бот автоматически отписывается. Отсюда следует правило: отвечайте на вебхук сразу, а долгую работу выносите дальше по цепочке.
- Сравните заголовок X-Max-Bot-Api-Secret с сохранённым секретом; при несовпадении сценарий останавливается без записи.
- Сохраните идентификатор события или сообщения и проверяйте его перед созданием заявки: повторная доставка обязана оставаться без второй карточки.
- Определите тип события: bot_started приходит при первом запуске бота клиентом или его возобновлении, message_created означает сообщение с текстом заявки.
- Выпишите только нужные поля: идентификатор клиента, текст, время. Остальные поля остаются вне карточки.
Тип события определяет ветку сценария. Запуск бота клиентом (bot_started) удобно использовать для приветствия и вопроса «что случилось»; сообщение с текстом (message_created) запускает создание заявки. Если поле с текстом пустое, например клиент прислал только картинку, сценарий просит описание словами и заявку пока откладывает.
Принципы проверки отправителя и защиты от повторов подробно описаны в материале про входящие вебхуки n8n; для MAX они применяются без изменений. Заявки из MAX обычно появляются рядом с уже работающими каналами, поэтому приём заявки строят одинаково для всех.
Через какой канал заявки приходят к вам сейчас?
Оператор и ответ
Клиент получает ответ только после того, как оператор подтвердил текст. Сценарий записывает заявку в таблицу или учётную систему, формирует для оператора карточку с текстом клиента и предлагаемым ответом и останавливается. Предложение может подготовить языковая модель, но оформлять его как отправку без человека нельзя: машина объясняет и предлагает, человек сверяет.
- Запишите заявку в таблицу со статусом «принята» и сохраните идентификатор клиента из события.
- Передайте оператору карточку заявки: текст клиента, найденный в базе контекст и черновик ответа.
- Дождитесь подтверждения оператора во втором сценарии, который запускается его действием; без него ответ в MAX остаётся неотправленным.
- Отправьте узлом HTTP Request запрос POST на
/messagesс параметром получателя и полем text. Длина текста ограничена 4000 символами. - Смените статус заявки на «ответ отправлен» и сохраните время и имя оператора.
Текст, который уходит клиенту, оператор правит до отправки. Подтверждение хранится вместе с заявкой: кто нажал, когда и какой вариант отправлен. Если оператор отклонил предложенный ответ, сценарий записывает причину отказа, и по накопленным отказам владелец процесса видит, в каких типах заявок помощь модели слабее.
Для отправки используйте идентификатор пользователя в параметре запроса. Лимиты платформы такие: до двух сообщений в секунду в одну беседу и до тридцати запросов в секунду к API. Для заявок хватает с запасом, но при массовой рассылке понадобится очередь.
Перед запуском
Протестируйте полный путь на вымышленном клиенте, подключив к боту отдельный тестовый аккаунт: сообщение, запись, карточка оператору, подтверждение, ответ. Отдельно проверьте сбои: неверный секрет, повторная доставка, пустое сообщение, ответ на бота без заявки. Результаты фиксируйте в журнале с версией сценария. Подписку на рабочего бота переключайте после того, как все перечисленные сбои обработаны понятным образом: у тестового и боевого ботов разные токены и разные адреса вебхуков.
Поручите владельцу процесса решить, какие данные клиента попадают в таблицу и сколько хранятся. Если заявки содержат контакты физических лиц, сверьтесь с требованиями закона о персональных данных; отправную точку даёт статья про 152-ФЗ при работе с чат-ботом. Токен бота храните отдельно от сценария и меняйте при смене сотрудника, у которого был доступ.
Отслеживайте и обратную сторону: если вебхук долго отвечал ошибкой, MAX мог отписать бота, и заявки перестали приходить. Раз в день просматривайте число принятых событий; провал в ноль при обычной работе означает, что подписку нужно оформить заново.
Заведите тестового бота, одну подписку на message_created и сценарий из двух узлов: Webhook с проверкой секрета и запись события в таблицу. Когда события дойдут, добавляйте карточку оператора и ответ. Для проекта чат-бота с правами, журналом и приёмкой посмотрите, как мы делаем чат-боты для бизнеса.