Rispondere ai messaggi WhatsApp con un chatflow di Flowise

Perché Flowise ha bisogno di qualcosa davanti a sé?

Perché il webhook di Meta e l'API di Flowise parlano formati diversi. Meta verifica una destinazione con una GET che deve restituire hub.challenge come corpo grezzo, poi consegna ogni messaggio come POST JSON annidato. La Prediction API di Flowise si aspetta una POST a /api/v1/prediction/ seguita dall'id del flow, con un campo question. Nessuno dei due si adatta all'altro, quindi serve un ricevitore che faccia da traduttore.

Il ricevitore può essere un nodo Webhook di n8n, una route in Python o Node, o una qualsiasi funzione serverless. Risponde alla GET di verifica, controlla un lungo secret casuale inserito nell'URL del webhook, risponde subito 200 a Meta e solo dopo fa il lavoro. Il secret nell'URL è l'autenticazione che qui funziona: Meta firma le consegne con l'app secret del Tech Provider, che non viene mai condiviso, quindi l'header X-Hub-Signature-256 non può essere validato da parte tua.

Come deve chiamare la Prediction API il ricevitore?

Con il testo del cliente come question e il numero WhatsApp del cliente come sessione. Flowise accetta overrideConfig a ogni richiesta, e un sessionId al suo interno permette ai nodi di memoria di tenere una conversazione per persona, invece di mescolare tutti in un unico thread. Il numero del mittente nel payload del webhook è una chiave stabile e naturale per questo scopo.

Se il chatflow è protetto da una chiave API, il ricevitore la invia come bearer token. Imposta streaming su false, a meno che il ricevitore non sia costruito per ricomporre uno stream, dato che WhatsApp consegna un messaggio finito e non un token alla volta.

La risposta parte come messaggio di testo della Cloud API dallo stesso numero. È gratuito e consentito entro la finestra di 24 ore aperta dal messaggio del cliente. Qualsiasi cosa il flow voglia inviare più tardi, come un promemoria, deve essere un template approvato.

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 agente Flowise può usare il server MCP di EasyCoexistence?

Oggi no. Il Custom MCP di Flowise si collega a un server Streamable HTTP con un URL e un insieme di header, di solito un bearer token statico tenuto in una variabile di Flowise. Il server MCP di EasyCoexistence si autentica con OAuth, con un accesso dal browser e token che emette da sé, quindi non c'è nessuna chiave statica da mettere in un header.

La divisione che funziona è lasciare che sia il flow a decidere e il ricevitore a inviare. Il flow restituisce il testo da dire, oppure il nome di un template quando il cliente è rimasto in silenzio per più di un giorno, e il ricevitore effettua la chiamata alla Cloud API con il token del numero. In questo modo il token non sta mai dentro Flowise, e la regola delle 24 ore è applicata nel codice, controllando quando il contatto ha scritto l'ultima volta, invece di essere affidata a un modello che potrebbe dimenticarla.

I messaggi in arrivo continuano a passare solo dal webhook, qualunque sia il modo in cui avviene l'invio.

Errori comuni

• Omettere sessionId. Ogni cliente condivide allora la stessa memoria, e i dati di una persona possono comparire nella risposta a un'altra.
• Aspettare Flowise prima di rispondere a Meta. Un 200 lento viene ritentato, quindi lo stesso messaggio viene elaborato due volte.
• Lasciare che il flow invii testo libero un giorno dopo. Fuori dalla finestra Meta lo rifiuta con l'errore 131047.

Domande frequenti

Continua a leggere