Répondre aux messages WhatsApp avec une app Dify

Meta peut-il envoyer les messages WhatsApp directement à Dify ?

Pas de manière à finaliser la poignée de main. Avant de livrer quoi que ce soit, Meta appelle la destination avec un GET et attend la valeur hub.challenge en corps de réponse brut. Le Webhook Trigger de Dify n'accepte qu'une seule méthode HTTP par trigger, et sa documentation indique qu'un corps de réponse non JSON est converti automatiquement en JSON : OK revient donc sous forme d'objet message. Le challenge ne peut jamais être renvoyé à l'identique, et Meta ne commence jamais à livrer.

Il faut donc placer un petit élément devant. Un nœud Webhook n8n, une route en Python ou Node, ou une fonction serverless répond au GET, accepte le POST et transmet le texte à Dify. C'est aussi ce récepteur qui vérifie le long secret aléatoire contenu dans l'URL du webhook, car l'en-tête X-Hub-Signature-256 est signé avec l'app secret du Tech Provider et ne peut pas être validé par le client.

Comment le récepteur dialogue-t-il avec l'app Dify ?

Avec un seul appel à la Service API de Dify : POST /chat-messages, authentifié par la clé d'API de l'app. Le corps contient query, le texte du client, et user, un identifiant que vous définissez. Utilisez le numéro WhatsApp de l'expéditeur comme user, et conservez le conversation_id renvoyé par Dify pour que le message suivant de la même personne poursuive la même conversation.

response_mode compte. Le mode blocking répond une fois la réponse complète, et la documentation de Dify avertit que sur Dify Cloud une longue génération peut être coupée par le proxy en bordure. Les apps de type Agent ne prennent en charge que le streaming, et une requête blocking échoue avec une erreur 400. Un récepteur qui lit le flux et envoie un seul message WhatsApp à la fin est la forme la plus robuste.

La réponse repart ensuite sous forme de message texte via la Cloud API vers le même numéro, sans frais dans la fenêtre de 24 heures ouverte par le message du client.

Qu'apporte le serveur MCP dans Dify ?

La possibilité, pour un agent Dify, d'agir sur le numéro sans que vous câbliez chaque appel. Dify se connecte aux serveurs MCP en HTTP et, par défaut, s'enregistre auprès du serveur via l'enregistrement dynamique de client OAuth, ce que prend en charge le serveur MCP d'EasyCoexistence. Ajoutez-le dans Tools, connectez-vous une fois, et l'agent obtient les outils : lister les numéros, vérifier la santé d'un numéro, envoyer un message, envoyer un template approuvé, lire le statut d'un template.

C'est le bon endroit pour le travail proactif : un workflow Dify qui relance le lendemain doit utiliser send_template, car un texte libre hors de la fenêtre renvoie l'erreur 131047, et les descriptions des outils le précisent au modèle.

Ce que MCP ne peut pas faire, c'est réveiller Dify quand un client écrit. Le protocole fonctionne en requête et réponse : les messages entrants continuent donc d'arriver par le webhook et le récepteur placé devant.

Erreurs courantes

• Utiliser l'URL d'un Webhook Trigger Dify comme destination du webhook. Le challenge revient encapsulé dans du JSON et Meta ne vérifie jamais l'endpoint.
• Envoyer une requête blocking à une app Dify de type Agent. Ces apps ne prennent en charge que le streaming, et l'appel échoue avec une erreur 400.
• Utiliser une nouvelle valeur de user à chaque message. Dify rattache les conversations à user : chaque message ouvre alors une nouvelle conversation sans mémoire.

Questions fréquemment posées

Poursuivre la lecture