Answer WhatsApp messages with a Dify app

Can Meta send WhatsApp messages straight to Dify?

Not in a way that completes the handshake. Before Meta delivers anything it calls the destination with a GET and expects the hub.challenge value back as the raw response body. Dify's Webhook Trigger accepts one HTTP method per trigger, and its documentation says a non-JSON response body is automatically converted to JSON, so OK comes back as a message object. The challenge can never be echoed exactly, and Meta never starts delivering.

So something small sits in front. An n8n Webhook node, a route in Python or Node, or a serverless function answers the GET, accepts the POST, and hands the text to Dify. That receiver is also where the long random secret in the webhook URL is checked, since the X-Hub-Signature-256 header is signed with the Tech Provider's app secret and cannot be validated by the customer.

How does the receiver talk to the Dify app?

With one call to Dify's Service API: POST /chat-messages, authenticated with the app's API key. The body carries query, the customer's text, and user, an identifier you define. Use the sender's WhatsApp number as user, and keep the conversation_id Dify returns so the next message from the same person continues the same conversation.

response_mode matters. Blocking returns once the answer is complete, and Dify's documentation warns that on Dify Cloud a long generation can be cut off by the edge proxy. Agent apps support streaming only, and a blocking request to one fails with 400. A receiver that reads the stream and sends one WhatsApp message at the end is the robust shape.

The reply then goes out as a Cloud API text message to the same number, which is free inside the 24 hour window the customer's message opened.

What does the MCP server add inside Dify?

The ability for a Dify agent to act on the number without you wiring each call. Dify connects to MCP servers over HTTP and, by default, registers itself with the server through OAuth dynamic client registration, which is what the EasyCoexistence MCP server supports. Add it under Tools, sign in once, and the agent gets the tools: list the numbers, check a number's health, send a message, send an approved template, read template status.

That is the right home for proactive work: a Dify workflow that follows up the next day has to use send_template, because free text outside the window returns error 131047, and the tool descriptions say so to the model.

What MCP cannot do is wake Dify up when a customer writes. The protocol is request and response, so incoming messages still arrive through the webhook and the receiver in front.

Common mistakes

• Using a Dify Webhook Trigger URL as the webhook destination. The challenge comes back wrapped in JSON and Meta never verifies the endpoint.
• Sending a blocking request to a Dify Agent app. Agent apps support streaming only, and the call fails with 400.
• Using a fresh user value per message. Dify scopes conversations to user, so every message starts a new conversation with no memory.

Frequently asked questions

Keep reading