Responde mensajes de WhatsApp con una app de Dify

¿Puede Meta enviar mensajes de WhatsApp directamente a Dify?

No de una forma que complete el handshake. Antes de entregar nada, Meta llama al destino con un GET y espera recibir el valor de hub.challenge como cuerpo de respuesta sin modificar. El Webhook Trigger de Dify acepta un único método HTTP por trigger, y su documentación dice que un cuerpo de respuesta que no sea JSON se convierte automáticamente a JSON, de modo que OK vuelve como un objeto de mensaje. El challenge nunca puede devolverse exactamente igual, y Meta no empieza a entregar.

Por eso hace falta algo pequeño delante. Un nodo Webhook de n8n, una ruta en Python o Node, o una función serverless responde al GET, acepta el POST y pasa el texto a Dify. Ese receptor es también el lugar donde se comprueba el secreto largo y aleatorio de la URL del webhook, ya que el encabezado X-Hub-Signature-256 se firma con el app secret del Tech Provider y el cliente no puede validarlo.

¿Cómo habla el receptor con la app de Dify?

Con una sola llamada a la Service API de Dify: POST /chat-messages, autenticada con la clave de API de la app. El cuerpo lleva query, el texto del cliente, y user, un identificador que defines tú. Usa el número de WhatsApp del remitente como user y conserva el conversation_id que devuelve Dify, para que el siguiente mensaje de la misma persona continúe la misma conversación.

response_mode importa. Blocking devuelve la respuesta cuando está completa, y la documentación de Dify advierte de que en Dify Cloud el proxy de borde puede cortar una generación larga. Las apps de tipo agente solo admiten streaming, y una petición bloqueante a una de ellas falla con 400. Un receptor que lee el stream y envía un único mensaje de WhatsApp al final es la forma más robusta.

La respuesta sale después como mensaje de texto de la Cloud API al mismo número, lo cual es gratis dentro de la ventana de atención de 24 horas que abrió el mensaje del cliente.

¿Qué aporta el servidor MCP dentro de Dify?

Que un agente de Dify pueda actuar sobre el número sin que tengas que cablear cada llamada. Dify se conecta a servidores MCP por HTTP y, por defecto, se registra en el servidor mediante registro dinámico de clientes de OAuth, que es lo que admite el servidor MCP de EasyCoexistence. Añádelo en Tools, inicia sesión una vez y el agente recibe las herramientas: listar los números, comprobar el estado de un número, enviar un mensaje, enviar una plantilla aprobada y leer el estado de una plantilla.

Ese es el lugar adecuado para el trabajo proactivo: un flujo de Dify que hace seguimiento al día siguiente tiene que usar send_template, porque el texto libre fuera de la ventana devuelve el error 131047, y las descripciones de las herramientas se lo dicen al modelo.

Lo que MCP no puede hacer es despertar a Dify cuando un cliente escribe. El protocolo es de petición y respuesta, así que los mensajes entrantes siguen llegando por el webhook y el receptor que está delante.

Errores comunes

• Usar la URL de un Webhook Trigger de Dify como destino del webhook. El challenge vuelve envuelto en JSON y Meta nunca verifica el endpoint.
• Enviar una petición bloqueante a una app de tipo agente de Dify. Las apps de agente solo admiten streaming, y la llamada falla con 400.
• Usar un valor de user nuevo en cada mensaje. Dify asocia las conversaciones a user, así que cada mensaje abre una conversación nueva sin memoria.

Preguntas frecuentes

Sigue leyendo