WhatsApp-Nachrichten mit einer Dify-App beantworten

Kann Meta WhatsApp-Nachrichten direkt an Dify senden?

Nicht so, dass der Handshake gelingt. Bevor Meta etwas zustellt, ruft es das Ziel mit einem GET auf und erwartet den Wert hub.challenge als rohen Antwortbody zurück. Der Webhook Trigger von Dify akzeptiert pro Trigger nur eine HTTP-Methode, und laut Dokumentation wird ein Antwortbody, der kein JSON ist, automatisch in JSON umgewandelt. Aus OK wird also ein Nachrichtenobjekt. Die Challenge lässt sich nie exakt zurückgeben, und Meta beginnt nie mit der Zustellung.

Deshalb sitzt etwas Kleines davor. Ein n8n-Webhook-Node, eine Route in Python oder Node oder eine Serverless-Funktion beantwortet den GET, nimmt den POST an und gibt den Text an Dify weiter. Dieser Receiver ist auch der Ort, an dem das lange, zufällige Geheimnis in der Webhook-URL geprüft wird, denn der Header X-Hub-Signature-256 wird mit dem App Secret des Tech Providers signiert und kann vom Kunden nicht validiert werden.

Wie spricht der Receiver mit der Dify-App?

Mit einem einzigen Aufruf der Service API von Dify: POST /chat-messages, authentifiziert mit dem API-Schlüssel der App. Der Body enthält query, den Text des Kunden, und user, eine von Ihnen festgelegte Kennung. Verwenden Sie die WhatsApp-Nummer des Absenders als user und speichern Sie die conversation_id, die Dify zurückgibt, damit die nächste Nachricht derselben Person das Gespräch fortsetzt.

response_mode ist wichtig. Blocking antwortet erst, wenn die Antwort vollständig ist, und die Dokumentation von Dify warnt, dass bei Dify Cloud eine lange Generierung vom Edge-Proxy abgebrochen werden kann. Agent-Apps unterstützen nur Streaming, eine Blocking-Anfrage an sie schlägt mit 400 fehl. Robust ist ein Receiver, der den Stream liest und am Ende eine einzige WhatsApp-Nachricht sendet.

Die Antwort geht dann als Textnachricht über die Cloud API an dieselbe Nummer. Das kostet nichts, solange das 24-Stunden-Fenster offen ist, das die Nachricht des Kunden geöffnet hat.

Was bringt der MCP-Server innerhalb von Dify?

Ein Dify-Agent kann auf der Nummer handeln, ohne dass Sie jeden Aufruf einzeln verdrahten. Dify verbindet sich per HTTP mit MCP-Servern und registriert sich standardmäßig per OAuth Dynamic Client Registration beim Server. Genau das unterstützt der EasyCoexistence MCP-Server. Fügen Sie ihn unter Tools hinzu, melden Sie sich einmal an, und der Agent erhält die Tools: Nummern auflisten, den Zustand einer Nummer prüfen, eine Nachricht senden, ein genehmigtes Template senden, den Status eines Templates lesen.

Das ist der richtige Ort für proaktive Arbeit: Ein Dify-Workflow, der am nächsten Tag nachfasst, muss send_template verwenden, denn Freitext außerhalb des Fensters liefert den Fehler 131047, und die Tool-Beschreibungen sagen das dem Modell ausdrücklich.

Was MCP nicht kann: Dify wecken, wenn ein Kunde schreibt. Das Protokoll arbeitet nach dem Prinzip Anfrage und Antwort, eingehende Nachrichten kommen also weiterhin über den Webhook und den vorgeschalteten Receiver.

Häufige Fehler

• Die URL eines Dify Webhook Trigger als Webhook-Ziel verwenden. Die Challenge kommt in JSON verpackt zurück, und Meta verifiziert den Endpoint nie.
• Eine Blocking-Anfrage an eine Dify-Agent-App senden. Agent-Apps unterstützen nur Streaming, und der Aufruf schlägt mit 400 fehl.
• Für jede Nachricht einen neuen user-Wert verwenden. Dify ordnet Gespräche dem user zu, daher beginnt jede Nachricht ein neues Gespräch ohne Gedächtnis.

Häufig gestellte Fragen

Weiterlesen