Answer WhatsApp messages with a Flowise chatflow

Why does Flowise need something in front of it?

Because Meta's webhook and Flowise's API speak different shapes. Meta verifies a destination with a GET that must return hub.challenge as the raw body, then delivers each message as a nested JSON POST. Flowise's Prediction API expects a POST to /api/v1/prediction/ followed by the flow id, with a question field. Neither will adapt to the other, so a receiver translates.

The receiver can be an n8n Webhook node, a route in Python or Node, or any serverless function. It answers the verification GET, checks a long random secret placed in the webhook URL, replies 200 to Meta straight away, and then does the work. The secret in the URL is the authentication that works here: Meta signs deliveries with the Tech Provider's app secret, which is never shared, so the X-Hub-Signature-256 header cannot be validated on your side.

How should the receiver call the Prediction API?

With the customer's text as question and the customer's WhatsApp number as the session. Flowise accepts overrideConfig on each request, and a sessionId inside it is what lets memory nodes keep one conversation per person instead of mixing everyone into one thread. The sender's number from the webhook payload is a stable, natural key for that.

If the chatflow is protected with an API key, the receiver sends it as a bearer token. Set streaming to false unless the receiver is built to assemble a stream, since WhatsApp delivers one finished message rather than a token at a time.

The answer goes out as a Cloud API text message from the same number. That is free and allowed inside the 24 hour window the customer's message opened. Anything the flow wants to send later, such as a reminder, has to be an approved template.

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

Can a Flowise agent use the EasyCoexistence MCP server?

Not today. Flowise's Custom MCP connects to a Streamable HTTP server with a URL and a set of headers, typically a static bearer token held in a Flowise variable. The EasyCoexistence MCP server authenticates with OAuth, with a browser sign-in and tokens it issues itself, so there is no static key to put in a header.

The working split is to let the flow decide and the receiver send. The flow returns the text to say, or the name of a template when the customer has been quiet for more than a day, and the receiver makes the Cloud API call with the number's token. The token then never sits inside Flowise, and the 24 hour rule is enforced in code by checking when the contact last wrote, rather than left to a model that may forget it.

Incoming messages still arrive only through the webhook, whichever way the sending is done.

Common mistakes

• Omitting sessionId. Every customer then shares one memory, and one person's details can surface in another person's reply.
• Waiting for Flowise before answering Meta. A slow 200 gets retried, so the same message is processed twice.
• Letting the flow send free text a day later. Outside the window Meta refuses it with error 131047.

Frequently asked questions

Keep reading