Отвечайте на сообщения WhatsApp с помощью приложения Dify

Может ли Meta отправлять сообщения WhatsApp прямо в Dify?

Так, чтобы рукопожатие завершилось, нет. Прежде чем что-либо доставить, Meta обращается к адресу назначения методом GET и ожидает получить значение hub.challenge как неизменённое тело ответа. Webhook Trigger в Dify принимает один метод HTTP на каждый триггер, а в документации сказано, что тело ответа не в формате JSON автоматически преобразуется в JSON, поэтому OK возвращается как объект сообщения. Точно повторить challenge невозможно, и Meta так и не начинает доставку.

Поэтому перед Dify нужно поставить что-то небольшое. Узел Webhook в n8n, маршрут на Python или Node либо serverless-функция отвечает на GET, принимает POST и передаёт текст в Dify. Именно в этом приёмнике проверяется длинный случайный секрет в URL вебхука, поскольку заголовок X-Hub-Signature-256 подписан секретом приложения Tech Provider, и клиент не может его проверить.

Как приёмник общается с приложением Dify?

Одним вызовом Service API Dify: POST /chat-messages с авторизацией по API-ключу приложения. В теле передаются query, то есть текст клиента, и user, идентификатор, который определяете вы. Используйте в качестве user номер WhatsApp отправителя и сохраняйте conversation_id, который возвращает Dify, чтобы следующее сообщение от того же человека продолжало тот же диалог.

Важен параметр response_mode. Режим blocking возвращает ответ, когда он полностью готов, и в документации Dify предупреждается, что в Dify Cloud долгую генерацию может оборвать пограничный прокси. Приложения-агенты поддерживают только streaming, а запрос в режиме blocking к ним завершается ошибкой 400. Надёжный вариант: приёмник читает поток и в конце отправляет одно сообщение WhatsApp.

Затем ответ уходит как текстовое сообщение через Cloud API на тот же номер. Это бесплатно в пределах окна обслуживания клиентов в 24 часа, которое открыло сообщение клиента.

Что добавляет сервер MCP внутри Dify?

Он позволяет агенту Dify действовать с номером без того, чтобы вы вручную подключали каждый вызов. Dify подключается к серверам MCP по HTTP и по умолчанию регистрируется на сервере через динамическую регистрацию клиента OAuth, которую поддерживает сервер EasyCoexistence MCP. Добавьте его в разделе «Инструменты», войдите один раз, и агент получит инструменты: список номеров, проверка состояния номера, отправка сообщения, отправка одобренного шаблона, чтение статуса шаблона.

Это подходящее место для проактивной работы: рабочий процесс Dify, который связывается с клиентом на следующий день, должен использовать send_template, потому что свободный текст вне окна возвращает ошибку 131047, и описания инструментов сообщают об этом модели.

Чего MCP не умеет, так это пробуждать Dify, когда клиент пишет. Протокол работает по схеме запрос и ответ, поэтому входящие сообщения по-прежнему приходят через вебхук и приёмник перед Dify.

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

• Использовать URL Webhook Trigger из Dify как адрес назначения вебхука. Challenge возвращается обёрнутым в JSON, и Meta никогда не подтверждает эндпоинт.
• Отправлять запрос в режиме blocking к приложению-агенту Dify. Приложения-агенты поддерживают только streaming, и вызов завершается ошибкой 400.
• Подставлять новое значение user для каждого сообщения. Dify привязывает диалоги к user, поэтому каждое сообщение начинает новый диалог без памяти.

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

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