WhatsApp Business Trigger
The WhatsApp Business trigger starts your flow when a customer messages a connected WhatsApp Business number. It supports the full range of WhatsApp message types — text, media, buttons, interactive lists, form submissions, reactions, and more — and Flowera handles all the Meta Cloud API plumbing for you.
This page covers setting up the trigger inside a flow. Connecting the WhatsApp number itself happens once in the Channels section.
The WhatsApp number must already be connected to Flowera (via Embedded Signup) before it appears in the account dropdown here. See the Credentials section for account connection.
Adding it to a flow
On the Start node, open Webhooks, add a webhook, and set Webhook Type to WhatsApp Business.
Inputs
| Parameter | Description | Required |
|---|---|---|
| Webhook Name | A unique name for this webhook (e.g. whatsapp-support). Used in variables like {{$webhook.whatsapp-support.senderId}}. | Yes |
| WhatsApp Account | The connected WhatsApp Business account this trigger listens to. | Yes |
| WhatsApp Message Types | Which incoming message types start the flow (see the 13 types below). | Yes |
| Batch Messages | When on, a customer's rapid-fire messages are combined into one response. On by default. | No |
Message types
Under WhatsApp Message Types you choose which kinds of incoming message trigger the flow. You can select any combination:
| Message type | Triggers on… |
|---|---|
| Text | A plain text message. |
| Images | A photo the customer sends. |
| Videos | A video message. |
| Audio | A voice note or audio clip. |
| Documents | A PDF, Word file, or other document. |
| Stickers | A WhatsApp sticker. |
| Location | A shared location (latitude/longitude). |
| Contacts | A shared contact card. |
| Button Replies | A tap on a reply button you sent. |
| Interactive Lists | A selection from an interactive list you sent. |
| Form Responses 📝 | A submitted WhatsApp Flow form (nfm_reply). |
| Reactions | An emoji reaction to a message. |
| Orders | A cart/order submitted from a product catalog. |
Message types already claimed by another flow on the same number are hidden here, so two flows never receive the same type. This lets you route (say) support text to one flow and catalog orders to another.
The type that fired is available as {{$webhook.<name>.eventType}}, with text as {{$question}} and rich fields like {{$webhook.<name>.location}}, {{$webhook.<name>.buttonPayload}}, {{$webhook.<name>.listReplyId}}, {{$webhook.<name>.reactionEmoji}}, {{$webhook.<name>.formResponse}}, {{$webhook.<name>.order}}, and {{$webhook.<name>.referredProduct}}. A submitted form also gives you {{$webhook.<name>.formResponseText}} (the answers as a readable label: value summary) and {{$webhook.<name>.flowChatflowId}} (which flow the form was sent from). See Variables for the full list.
Form submissions arrive as eventType: nfm_reply, which is distinct from interactive (button and list replies). To receive submitted forms, you must explicitly enable Form Responses 📝 — a flow set up only for Interactive Lists or Button Replies will not catch them.
Orders and product questions
If you sell from a product catalog, two events carry extra data.
A submitted cart fires with eventType: order. {{$question}} is a readable summary, and
{{$webhook.<name>.order}} holds the parsed cart:
| Field | What it is |
|---|---|
items | One entry per line: sku, quantity, unitPrice, lineTotal, currency |
total | Sum of every line |
currency | Currency of the cart |
itemCount | Number of distinct products |
note | Free text the customer attached when sending the cart |
catalogId | Catalog the products came from |
A product question — the customer taps Message business from a product card and types something
— arrives as an ordinary text message, with the product they were looking at in
{{$webhook.<name>.referredProduct}} (catalogId and sku). Without it, a message like
"Is this still available?" has no referent.
Meta sends product ids, never product names. To greet the customer with a real product name, map the SKUs yourself in the flow.
Enable Orders 🛒 in WhatsApp Message Types, or carts will not trigger the flow at all.
Batch Messages
Customers often send several short messages back to back. With Batch Messages on (the default), Flowera briefly waits, combines them into a single input, and runs the flow once — so the bot responds to the whole message instead of each fragment. Turn it off to reply to every message the moment it arrives.
One exception: submitted carts. An order is a discrete business event, so if a customer sends more than one cart inside the same waiting window, each cart gets its own flow run — in the order they arrived — rather than being merged into one. Any ordinary messages and attachments from that window ride along with the final run. Design order-handling flows to handle one cart per run and you get the right behaviour in both cases. Runs per window are capped, and once the cap is reached the remaining carts share the final run. A flow containing a Wait or Human Input node is never split this way, because those pause mid-run.
Example
A WhatsApp support bot: webhook named whatsapp-support, listening for Text and Audio. Text arrives as {{$question}}; voice notes are transcribed automatically and read from {{$uploads.audios[0].transcript}}. An Agent (optionally backed by a knowledge base) answers and replies on WhatsApp.
Not receiving messages?
If Credentials → WhatsApp accounts shows a red Not receiving messages badge on a number, the number connected but the step that subscribes it to incoming-message notifications did not confirm. Nothing your flow can do will help until that is cleared, because the messages never arrive.
- Click Refresh status on that number first. Flowera re-checks with Meta and clears the badge if the subscription is actually in place. Most of these warnings are a lost confirmation during setup rather than a missing subscription, so this resolves them.
- Reconnect the account only if the badge survives a refresh. That re-runs the connection and sets the subscription up again.
Reconnecting is the second step on purpose — it takes you back through the whole WhatsApp connection flow, and it is usually unnecessary.
Tips
- Enable only the message types your flow actually handles — fewer types means cleaner routing.
- Use a Condition on
{{$webhook.<name>.eventType}}to branch between text, orders, and form responses in one flow. - WhatsApp has a 24-hour messaging window: to reach a customer after 24 hours of silence you need an approved template (see Batch Run for template campaigns).