Répondre aux messages WhatsApp avec un chatflow Flowise

Pourquoi Flowise a-t-il besoin d'un intermédiaire ?

Parce que le webhook de Meta et l'API de Flowise n'utilisent pas le même format. Meta vérifie une destination avec une requête GET qui doit renvoyer hub.challenge comme corps brut, puis livre chaque message sous forme de POST JSON imbriqué. La Prediction API de Flowise attend un POST vers /api/v1/prediction/ suivi de l'identifiant du flow, avec un champ question. Ni l'un ni l'autre ne s'adaptera à l'autre, donc un récepteur fait la traduction.

Le récepteur peut être un nœud Webhook n8n, une route en Python ou Node, ou n'importe quelle fonction serverless. Il répond au GET de vérification, contrôle un long secret aléatoire placé dans l'URL du webhook, répond 200 à Meta immédiatement, puis fait le travail. Le secret dans l'URL est l'authentification qui fonctionne ici : Meta signe les livraisons avec l'app secret du Tech Provider, qui n'est jamais partagé, donc l'en-tête X-Hub-Signature-256 ne peut pas être validé de votre côté.

Comment le récepteur doit-il appeler la Prediction API ?

Avec le texte du client comme question et le numéro WhatsApp du client comme session. Flowise accepte overrideConfig à chaque requête, et un sessionId à l'intérieur permet aux nœuds de mémoire de garder une conversation par personne au lieu de tout mélanger dans un seul fil. Le numéro de l'expéditeur, présent dans le payload du webhook, est pour cela une clé stable et naturelle.

Si le chatflow est protégé par une clé d'API, le récepteur l'envoie comme bearer token. Mettez streaming à false, sauf si le récepteur est prévu pour assembler un flux, car WhatsApp livre un message terminé et non un token à la fois.

La réponse part comme un message texte de la Cloud API depuis le même numéro. C'est gratuit et autorisé dans la fenêtre de 24 heures ouverte par le message du client. Tout ce que le flow veut envoyer plus tard, comme un rappel, doit être un template approuvé.

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" }
}

Un agent Flowise peut-il utiliser le serveur MCP d'EasyCoexistence ?

Pas aujourd'hui. Le Custom MCP de Flowise se connecte à un serveur Streamable HTTP avec une URL et un ensemble d'en-têtes, généralement un bearer token statique conservé dans une variable Flowise. Le serveur MCP d'EasyCoexistence s'authentifie avec OAuth, via une connexion dans le navigateur et des tokens qu'il émet lui-même, donc il n'y a aucune clé statique à placer dans un en-tête.

La répartition qui fonctionne : le flow décide et le récepteur envoie. Le flow renvoie le texte à dire, ou le nom d'un template lorsque le client est silencieux depuis plus d'un jour, et le récepteur fait l'appel à la Cloud API avec le token du numéro. Le token ne se retrouve ainsi jamais dans Flowise, et la règle des 24 heures est appliquée dans le code en vérifiant la date du dernier message du contact, plutôt que confiée à un modèle qui peut l'oublier.

Les messages entrants arrivent toujours uniquement par le webhook, quelle que soit la manière dont l'envoi est réalisé.

Erreurs courantes

• Omettre sessionId. Tous les clients partagent alors la même mémoire, et les informations d'une personne peuvent apparaître dans la réponse à une autre.
• Attendre Flowise avant de répondre à Meta. Un 200 trop lent est relancé, et le même message est donc traité deux fois.
• Laisser le flow envoyer du texte libre un jour plus tard. Hors de la fenêtre, Meta le refuse avec l'erreur 131047.

Questions fréquemment posées

Poursuivre la lecture