WhatsApp-Nachrichten mit einem Flowise-Chatflow beantworten

Warum braucht Flowise etwas davor?

Weil der Webhook von Meta und die API von Flowise unterschiedliche Formate verwenden. Meta verifiziert ein Ziel mit einem GET, der hub.challenge als rohen Body zurückgeben muss, und liefert danach jede Nachricht als verschachtelten JSON-POST. Die Prediction API von Flowise erwartet einen POST an /api/v1/prediction/ gefolgt von der Flow-ID, mit einem Feld question. Keine der beiden Seiten passt sich an die andere an, deshalb übersetzt ein Receiver.

Der Receiver kann ein n8n-Webhook-Node sein, eine Route in Python oder Node oder eine beliebige Serverless-Funktion. Er beantwortet den Verifizierungs-GET, prüft ein langes zufälliges Secret in der Webhook-URL, antwortet Meta sofort mit 200 und erledigt dann die eigentliche Arbeit. Das Secret in der URL ist hier die funktionierende Authentifizierung: Meta signiert Zustellungen mit dem App Secret des Tech Providers, das nie weitergegeben wird, daher lässt sich der Header X-Hub-Signature-256 auf Ihrer Seite nicht validieren.

Wie sollte der Receiver die Prediction API aufrufen?

Mit dem Text des Kunden als question und der WhatsApp-Nummer des Kunden als Session. Flowise akzeptiert bei jeder Anfrage overrideConfig, und eine darin enthaltene sessionId sorgt dafür, dass Memory-Nodes pro Person eine eigene Unterhaltung führen, statt alle in einem Thread zu vermischen. Die Nummer des Absenders aus der Webhook-Payload ist dafür ein stabiler, naheliegender Schlüssel.

Ist der Chatflow mit einem API-Schlüssel geschützt, sendet der Receiver ihn als Bearer-Token. Setzen Sie streaming auf false, solange der Receiver keinen Stream zusammensetzen kann, denn WhatsApp liefert eine fertige Nachricht und nicht ein Token nach dem anderen.

Die Antwort geht als Textnachricht der Cloud API von derselben Nummer hinaus. Das ist kostenlos und erlaubt, solange das 24-Stunden-Fenster offen ist, das die Nachricht des Kunden geöffnet hat. Alles, was der Flow später senden will, etwa eine Erinnerung, muss ein freigegebenes Template sein.

POST https://your-flowise-host/api/v1/prediction/<flow-id>
Authorization: Bearer <flowise-api-key>
Content-Type: application/json

{
  "question": "do you have anything friday?",
  "streaming": false,
  "overrideConfig": { "sessionId": "14155550188" }
}

Kann ein Flowise-Agent den EasyCoexistence MCP-Server nutzen?

Heute nicht. Das Custom MCP von Flowise verbindet sich mit einem Streamable-HTTP-Server über eine URL und mehrere Header, meist ein statisches Bearer-Token in einer Flowise-Variable. Der MCP-Server von EasyCoexistence authentifiziert per OAuth, mit Anmeldung im Browser und Token, die er selbst ausstellt, deshalb gibt es keinen statischen Schlüssel für einen Header.

Die praktikable Aufteilung: Der Flow entscheidet, der Receiver sendet. Der Flow gibt den zu sagenden Text zurück oder den Namen eines Templates, wenn sich der Kunde länger als einen Tag nicht gemeldet hat, und der Receiver führt den Cloud-API-Aufruf mit dem Token der Nummer aus. So liegt das Token nie in Flowise, und die 24-Stunden-Regel wird im Code durchgesetzt, indem geprüft wird, wann der Kontakt zuletzt geschrieben hat, statt sie einem Modell zu überlassen, das sie vergessen kann.

Eingehende Nachrichten kommen weiterhin nur über den Webhook an, egal wie gesendet wird.

Häufige Fehler

• sessionId weggelassen. Dann teilen sich alle Kunden ein Gedächtnis, und die Angaben einer Person können in der Antwort an eine andere auftauchen.
• Auf Flowise warten, bevor Meta eine Antwort bekommt. Eine langsame 200 wird erneut zugestellt, und dieselbe Nachricht wird zweimal verarbeitet.
• Den Flow einen Tag später Freitext senden lassen. Außerhalb des Fensters lehnt Meta das mit dem Fehler 131047 ab.

Häufig gestellte Fragen

Weiterlesen