What WhatsApp Flows are
Meta describes Flows as "a way to build structured interactions for business messaging." In practice, a Flow is a button in a WhatsApp message. The customer taps it and a form opens over the chat: a few screens with dropdowns, date pickers, checkboxes and text fields. When they finish, the answers come back to the business as one structured reply, not a string of messages someone has to piece together.
That fixes the oldest problem with WhatsApp for business. Free-text chat is great for questions and terrible for collecting a vehicle registration, an ID number, a preferred date and a suburb in the right order. A Flow collects them in one go and hands you clean, separate fields.
Meta's own packaged use cases cover pre-approved loans, insurance quotes, purchase intent and personalised offers. The same building blocks work for bookings, claims, applications, onboarding and surveys.
Source: WhatsApp Flows, Meta for Developers
Static Flows and Flows with live data
There are two kinds of Flow, and the difference decides how much engineering is involved.
| Static Flow | Flow with an endpoint | |
|---|---|---|
| What the customer sees | The same screens and options for everyone | Screens filled from your systems: their policy, today's open slots, a calculated quote |
| Moving between screens | Fixed (navigate) | Your endpoint decides the next screen (data_exchange) |
| Needs a server | No | Yes: an HTTPS endpoint with encryption |
| Meta health monitoring | Doesn't apply | Applies: slow or failing endpoints get throttled, then blocked |
| Good for | Simple sign-ups, feedback, fixed menus | Bookings, quotes, claims, applications, anything that looks something up |
Meta's advice is to call the endpoint only when a screen really needs fresh data, and to use plain navigation everywhere else. We follow that: a ten-screen application might only call your system twice.
How data_exchange endpoints work
Meta's documentation says it plainly: "upon screen submission, the flow can make a request to the endpoint to get the name of the next screen and the data to display on it." Your endpoint gets a data_exchange request when the Flow opens with live data, when a screen is submitted, when the customer goes back to a screen set to refresh, or when they pick an option that should change the screen.
Getting this right takes more than a web form. These are the parts we build and run:
- EncryptionEvery request arrives encrypted. The endpoint decrypts the AES key with your RSA private key, decrypts the payload with AES-GCM, and encrypts its reply with the same key. If it can't decrypt a request it must return HTTP 421 so WhatsApp re-fetches the public key. We create a separate key pair for each client, with rotation, and upload the signed public key to your number.
- Signature checksMeta signs each request in the
X-Hub-Signature-256header, using the secret of the Meta app linked to the Flow. We reject anything that doesn't match, and use signed flow tokens to tie each Flow to the right customer and conversation. - The 10-second limitMeta treats an endpoint request as timed out after 10 seconds and recommends replying in under 1 second. Your back office may be slower than that, so we design each screen around it: short lookups, data loaded ahead where possible, and a fallback screen instead of an error.
- Health checksWhatsApp periodically sends health check requests to the endpoints of published Flows. Meta won't let you publish a Flow until its endpoint is up and answers them.
- Getting the answers homeWhen the customer submits, the completed answers arrive as a WhatsApp reply. Our platform matches it to the conversation and sends it to your system through its API: a lead in your CRM, a claim in your claims system, a booking in your calendar. The next chat message can confirm it, or carry a payment link.
Sources: Implement endpoints for Flows · Flows error codes (timeout after 10 seconds)
Meta's health rules for Flows with an endpoint
Meta watches every endpoint-powered Flow for three things: error rate, latency and availability. It sends alerts when the endpoint's error rate crosses 5%, 10% or 50% over 30 minutes, and when p90 latency crosses 1, 5 or 7 seconds. If things keep getting worse, the Flow changes state:
| Flow state | What it means for you |
|---|---|
| Published | No restrictions |
| Throttled | You can send only 10 new messages with this Flow an hour. Customers can still open Flows they already have |
| Blocked | You can't send the Flow, and customers can't open Flows you sent earlier |
A blocked claims or booking Flow is a closed front door, so the endpoint matters as much as the form. Once the endpoint recovers, Meta moves the Flow back from Blocked to Throttled, then to Published, on its own.
Sources: Flows health and monitoring · Flows webhooks