Подключите WhatsApp к n8n через официальный Cloud API

Как сообщение WhatsApp попадает в сценарий n8n?

Meta отправляет каждое сообщение на номер по HTTP POST на единый URL, который вы указываете. Это и есть вся интеграция. Разместите узел Webhook n8n по рабочему URL, задайте его как адрес вебхука номера, и сценарий будет запускаться на каждом входящем сообщении.

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

Поскольку это Coexistence, то же сообщение остаётся в приложении WhatsApp Business на телефоне. На него может ответить сотрудник. Сценарий видит сообщение сотрудника, а сотрудник видит сообщение сценария, поэтому их ответы не накладываются друг на друга.

{
  "from": "14155550188",
  "id": "wamid.HBgLMTQxNTU1NTAxODgVAgAS",
  "timestamp": "1758412800",
  "type": "text",
  "text": { "body": "do you have anything friday?" }
}

Как сценарий отправляет ответ?

Через узел HTTP Request к Cloud API, используя идентификатор телефона и токен доступа номера. Оба значения доступны в панели управления или через коннектор MCP, если вы хотите, чтобы их получил ассистент.

Тип сообщения зависит от времени, и здесь чаще всего ошибаются. В течение 24 часов после последнего сообщения клиента можно отправлять обычный текст, составленный сценарием. После этого окна пройдёт только шаблон, заранее одобренный Meta. Сценарий, который отправляет лишь обычный текст, отлично выглядит при тестировании, потому что тест всегда проходит через несколько секунд после сообщения, а затем замолкает при первом настоящем ночном обращении.

Надёжная схема состоит из ветвления: проверьте, сколько времени прошло с последнего входящего сообщения, и выберите обычный текст или шаблон.

Может ли n8n использовать также коннектор MCP?

Да, и в этом n8n отличается от большинства платформ. Его узел MCP Client Tool подключается к удалённому MCP-серверу и поддерживает OAuth2, который нужен нам. Поэтому узел AI Agent в сценарии может напрямую вызывать наши инструменты.

Это важно, потому что большинство платформ автоматизации так не умеют. Make и Zapier запускают собственные MCP-серверы и не работают как клиенты, поэтому они не могут обращаться к стороннему серверу. n8n может.

Коннектор полезен для действий: узел-агент может решить отправить сообщение, проверить состояние номера или узнать статус одобрения шаблона во время выполнения сценария. Но он не заменяет вебхук, потому что MCP не умеет запускаться от входящего сообщения.

Что из двух должен использовать сценарий?

Оба, но для разных задач. Это не вопрос предпочтений.

Вебхук запускает процесс. Клиент пишет, Meta отправляет сообщение в ваш узел Webhook, и сценарий запускается. Эквивалента этому в MCP нет, потому что протокол работает по схеме «запрос и ответ», а не вызывается входящим событием.

MCP Client Tool нужен агенту внутри сценария, чтобы выполнять действия без жёстко заданного вызова. Если сценарий уже знает, что именно отправить, узел HTTP Request к Cloud API проще и оставляет меньше места для ошибок. Если решение принимает агент, коннектор предоставляет ему одиннадцать инструментов и правила из их описаний, включая окно 24 часа.

Чем это отличается от уже известных узлов WhatsApp для n8n?

Большинство найденных в интернете интеграций WhatsApp с n8n используют неофициальный шлюз, который входит в аккаунт как подключённое устройство. Начать с ним легко, но номер оказывается под угрозой, поскольку такой механизм нарушает правила WhatsApp, а Meta распознаёт характер трафика, а не конкретную библиотеку.

Другой распространённый вариант это официальный API без Coexistence. Он работает, но переносит номер. Приложение WhatsApp Business на нём перестаёт работать, и команде, которая отвечала клиентам весь день, приходится переходить в новый инструмент. Для большинства небольших компаний это неприемлемо, поэтому многие и выбрали неофициальные шлюзы.

Coexistence объединяет то, чего не хватало: официальный API и работающий телефон.

Распространённые ошибки

• Использование тестового URL n8n как адреса вебхука. Он перестаёт принимать запросы после закрытия редактора, поэтому сообщения больше некому доставлять.
• Отсутствие ответа на запрос проверки Meta. Перед доставкой сообщений Meta отправляет GET с challenge, и узел, который не возвращает его, никогда не получит сообщение.
• Ответ обычным текстом после окна 24 часа. С точки зрения сценария это выглядит как незаметная ошибка, и проходит только одобренный шаблон.

Часто задаваемые вопросы

Читайте дальше