Summarise this article with:
On this page
- What WhatsApp Flows are, and what they replace
- Endpoint vs non-endpoint Flows: the decision that shapes everything else
- The three version tracks, and why version drift breaks production
- Six WhatsApp Flow patterns that work for Indian businesses
- Flows, the customer service window, and the 1 October 2026 cost change
- What most teams get wrong about Flows
- Ship your first Flow: a ten-step rollout
- Get started with InfiQ
Most WhatsApp automation dies at the link. The greeting lands, the customer replies, your bot asks a question or two, and then it sends a URL to a web form. That is where the conversation stops being a conversation — the user leaves WhatsApp, meets a login wall or a slow mobile page, and never comes back.
WhatsApp Flows close that gap. A WhatsApp Flow is an interactive, multi-screen form that renders inside the WhatsApp chat itself, so a user can pick an appointment slot, choose a variant, upload a document or confirm an address without leaving the thread. Meta supports Flows on Android 6.0+ and iOS 12+, and support for Flows on WhatsApp Web only began rolling out in December 2025.
This guide covers what decides whether a Flow survives production: the endpoint decision, the three version tracks, six patterns, and the cost change of 1 October 2026.
Key points
- A WhatsApp Flow is a multi-screen interactive form that completes inside the chat, removing the browser handoff that loses most WhatsApp funnels their completions.
- A non-endpoint Flow holds all logic client-side and needs no server; an endpoint Flow calls a business-owned HTTPS server with encrypted payloads for live data and dynamic routing.
- WhatsApp Flows run on Android 6.0+ and iOS 12+, and Flow-on-Web support began rolling out in December 2025.
- Flows carry three independent version tracks: Flow JSON (up to 7.3 recommended for sending, publishing floor 5.1), Data API (4.0, shipped around November 2025 with a two-signature auth enhancement) and Message version (3).
- Flow versions become Frozen, then Expired, generally with 90 days' notice, which makes version drift the top cause of a Flow that worked last quarter and fails today.
- From 1 October 2026, Meta resumes charging for service messages and for utility messages sent inside an open 24-hour customer service window, both free today.
What WhatsApp Flows are, and what they replace
A WhatsApp Flow is a sequence of native screens — text inputs, dropdowns, date pickers, radio groups, checkboxes, document uploads, opt-in checkboxes — that a user moves through inside the chat and submits as one structured payload. Your backend receives clean fields, not a transcript to parse.
The alternative most teams start with is a bot that asks one question per message. That works for three fields and falls apart at six, because every turn is a fresh chance to type something unexpected, abandon the thread, or reply three hours later when context has gone. Treat WhatsApp interactive forms as the structured-data layer on top of your bot, not a replacement — the WhatsApp chatbot guide covers where free-text handling still wins.
Device support and where Flows do not render
Flows are supported on Android 6.0+ and iOS 12+ per Meta's WhatsApp Flows documentation. For a long time they did not render on WhatsApp Web or desktop at all; Flow-on-Web support began rolling out in December 2025, announced in the 11 November 2025 release notes.
So test the desktop experience before routing a critical journey through a Flow. And design every Flow so a user who cannot open it still has a path: a plain-text prompt sequence, a phone number, or an agent handoff in your shared inbox.
Endpoint vs non-endpoint Flows: the decision that shapes everything else
This is the first architectural decision and the one teams most often get wrong — endpoint Flows sound more capable, and then you own an uptime-critical HTTPS service.
A non-endpoint Flow is a Flow whose screens, options and navigation logic are entirely defined in the Flow JSON and executed client-side, with no server call during the interaction. An endpoint Flow is a Flow that calls a business-owned HTTPS server with encrypted request and response payloads, so screens can be built from live data and the next screen chosen at runtime.
| Decision factor | Non-endpoint Flow | Endpoint Flow |
|---|---|---|
| Where logic lives | Entirely in Flow JSON, client-side | Your server decides screens at runtime |
| Server required | No | Yes, with encrypted request/response handling |
| Live data (stock, slots, balances) | No — options are static | Yes, fetched per interaction |
| Conditional routing | Only what static JSON can express | Full — server picks the next screen |
| Validation | Client-side field rules only | Server-side, against your own records |
| Time to first Flow | Hours | Days to weeks, including security review |
| Ongoing burden | Version upkeep only | Version upkeep, uptime, latency, key rotation |
| Failure mode | Renders fine, data may be stale | Stalls or errors if your endpoint is slow |
| Best for | Qualification, feedback, static catalogues, consent | Live-calendar booking, order lookup, KYC |
| Data API version | Not applicable | 4.0 recommended |
The honest rule: start non-endpoint. Ship a static three-screen qualification Flow this week, learn where users drop, and go endpoint only when the journey needs data you cannot pre-load. A slow endpoint reads to the user as a broken WhatsApp, not a broken server. Note also that the security model tightened in the Data API 4.0 release around November 2025 with a two-signature auth enhancement.
The three version tracks, and why version drift breaks production
Flows do not have "a version". They have three, and they move independently. This is the most common reason a Flow that worked in March stops working in September.
| Track | What it governs | Recommended | Notes |
|---|---|---|---|
| Flow JSON | Screens, components, layout, client-side logic | Up to 7.3 for sending | Publishing floor currently 5.1 |
| Data API | Contract between WhatsApp and your endpoint | 4.0 | Shipped ~Nov 2025 with two-signature auth |
| Message version | The envelope that delivers the Flow | 3 (integer) | Independent; easy to leave stale |
Versions retire in two stages, per Meta's Flows versioning documentation. A version first becomes Frozen, meaning you can no longer publish new Flows on it while existing ones keep working. It then becomes Expired, meaning the Flow cannot be sent or opened at all. Meta generally gives around 90 days' notice before these transitions.
Ninety days sounds generous. In practice it is short, because the notice lands in developer release notes that nobody on the growth team reads, while the Flow that breaks was built by a contractor eighteen months ago. The pattern is an expiry that passes unnoticed and a Tuesday morning where lead qualification returns nothing and no code has changed.
Three defences, all boring. Record the Flow JSON, Data API and Message versions for every published Flow alongside its owner. Review them quarterly against Meta's current recommended and floor values. And alert on Flow completion volume, not only on errors, because an expired Flow fails quietly. When you hand-author Flow JSON this upkeep is your standing liability; in a managed builder such as InfiQ Flows, version targeting arrives as a platform update rather than a sprint ticket.
Six WhatsApp Flow patterns that work for Indian businesses
These six cover most of what Indian teams build. Screens are in order; the endpoint column says whether you can ship it statically.
| Pattern | Screens, in order | Endpoint needed | Typical carrying category |
|---|---|---|---|
| Lead qualification | 1. Intent · 2. Budget band · 3. Timeline · 4. City or locality · 5. Contact preference · 6. Confirmation | No | Marketing or utility, by content |
| Appointment booking | 1. Service type · 2. Branch or doctor · 3. Date · 4. Available slot · 5. Customer details · 6. Confirmation | Yes, for live slots | Utility |
| Order tracking | 1. Order lookup · 2. Status timeline · 3. Action chooser · 4. Details capture · 5. Confirmation | Yes | Utility |
| KYC document collection | 1. Purpose and consent · 2. Identity type · 3. Document upload · 4. Field confirmation · 5. Declaration · 6. Receipt | Yes | Utility |
| Feedback and NPS | 1. Score · 2. Reason picker · 3. Free-text comment · 4. Follow-up consent · 5. Thank-you | No | Utility |
| Catalogue configurator | 1. Category · 2. Variant · 3. Quantity · 4. Add-ons · 5. Summary · 6. Handoff | Either — static or live stock | Marketing or utility, by content |
Lead qualification is the fastest win and should stay non-endpoint: five taps replace a phone screen, and the payload lands in your CRM as fields, not a call recording. Appointment booking is the classic endpoint case, because showing a slot you cannot honour is worse than showing none. KYC document collection needs your strictest data-minimisation discipline — collect only what the purpose requires, state that purpose on screen one, keep retention short. India's DPDP regime makes the consent screen a legal artefact — collect valid, informed consent and take your own advice; the WhatsApp opt-in and DPDP guide covers the mechanics. Catalogue configurator and post-purchase Flows drive cart resumption in the abandoned cart recovery playbook.
Whether a Flow reaches the user attached to a template sent outside the customer service window, or as an interactive message inside an open one, decides which pricing category applies — confirm the current send options against Meta's Flows documentation before modelling cost.
Flows, the customer service window, and the 1 October 2026 cost change
The customer service window is the 24-hour period that opens when a user messages your business, during which you can reply outside the template system. Since per-message pricing arrived on 1 July 2025, utility templates and non-template messages sent inside an open window have been free, and service messages have been free since 1 November 2024.
Both of those free allowances end. Per Meta's pricing documentation for non-template messages, Meta resumes charging for service messages and for utility messages sent inside an open window from 1 October 2026. Two related dates: the Meta Business Agent Platform launched on 1 July 2026, and per-token billing for Meta Business Agent messages started on 1 August 2026 — the Meta Business Agent Platform pricing breakdown covers the budgeting consequences.
The October change turns Flows from a UX improvement into a cost lever. Today a bot that takes fourteen turns to resolve an order query costs the same as one that takes two. After 1 October 2026, message count inside the window matters again.
Worked example: a hypothetical D2C brand in Bengaluru
Take a hypothetical Bengaluru D2C brand handling 12,000 inbound support conversations a month, of which 9,000 are "where is my order" and "change my address" — the two most automatable intents.
- Today's design: a conversational bot resolves each one over an average of 14 in-window messages. Monthly total: 9,000 × 14 = 126,000 messages, currently costing nothing.
- Flow-led design: one carrying message plus a single Flow submission that returns status and changes the address in the same interaction. At 2 messages per conversation: 9,000 × 2 = 18,000 messages.
- Difference: 126,000 − 18,000 = 108,000 fewer chargeable messages a month, roughly an 86% reduction on those two intents.
At today's rates both cost the same. From 1 October 2026 the gap becomes 108,000 messages a month times the applicable India rate — utility is ₹0.19 per delivered message today (ex-GST), so roughly 108,000 × ₹0.19 a month at the current card.
Do not read that 86% as a promised rupee saving. Meta publishes rate cards as downloadable CSV and PDF files per market and category, and rates change only on 1 January, 1 April, 1 July or 1 October with defined notice periods, so pull the current card or use InfiQ's WhatsApp cost calculator before committing a budget number. Read the mechanism instead: verbosity acquires a price. To run that arithmetic on your own volumes, bring three months of conversation data to InfiQ Flows.
The category of the carrying message matters as much, because category is decided by content rather than intent — the template categories guide explains how one promotional clause turns a utility template into a marketing one.
What most teams get wrong about Flows
They build the Flow they want, not the Flow the user will finish. Every screen is a drop-off point, and six screens with one field each is almost always worse than three with two. Cut fields until it hurts, then add back only what completion data justifies.
They treat the Flow as the whole journey. A Flow is a data-capture instrument, not a conversation. The message before it has to earn the tap and the message after it has to confirm what happened, because a Flow that submits into silence teaches users the form did nothing.
They send Flows to people who never opted in. A Flow inside a marketing template is still a marketing template. WhatsApp dynamically caps how many marketing templates a single user receives across all businesses based on that user's recent read rate and inbox load, that cap is active in India, and a throttled send returns error 131049 — which you should not retry inside 24 hours. Interactive packaging does not buy permission you do not have.
They never instrument it. If you cannot see per-screen drop-off you are guessing. Wire Flow completion events into analytics like a checkout funnel; the WhatsApp webhooks guide covers the plumbing.
Ship your first Flow: a ten-step rollout
- Pick one intent with a measurable outcome — order status, appointment booking or lead qualification, not "customer service".
- Write the screens on paper first: field name, input type, required or optional, exact question wording.
- Decide non-endpoint or endpoint using the table above. Default to non-endpoint unless live data is required.
- Choose version targets explicitly — Flow JSON at or below 7.3 and above the 5.1 publishing floor, Data API 4.0 for endpoint Flows, Message version 3 — and record them.
- Build it. Hand-author the JSON against Meta's Flows guides, or assemble it in a drag-and-drop builder such as InfiQ Flows if you would rather not own the schema.
- Get the carrying template approved. Review takes up to 24 hours, and appeals are reviewed within 24 hours and must include a sample.
- Test on real devices — one low-end Android, one iOS, one desktop session. Test the abandon path: open the Flow, close it halfway, check what your system recorded.
- Pilot on 200 to 500 contacts. Watch per-screen completion, time to complete, and inbound "what is this" replies — the last means the carrying message is unclear.
- Instrument before scaling: completion rate, drop-off by screen, endpoint latency, and an alert if daily completions fall below a floor.
- Add the Flow to your version register with an owner and a review date.
One note on step 5. Hand-authoring against the WhatsApp Flows API gives you full control and full liability — schema validation, version migration and every edge case are yours. A builder trades control for time to first Flow and lower upkeep, which is the whole trade.
Get started with InfiQ
The teams that get value from Flows are not the ones with the most screens. They picked one high-volume intent, shipped a three-screen non-endpoint Flow in a week, measured drop-off, and only then went near an endpoint server. With in-window messages chargeable again from 1 October 2026, that discipline becomes a line item.
Ready to replace your longest support thread with a three-screen Flow? Start your 7-day free trial — InfiQ gets you live on the official WhatsApp Business API in about 2 hours, with InfiQ Flows as a drag-and-drop builder and a shared team inbox for everything a Flow hands off. Or book a walkthrough if you want to see it mapped to your own use case first.
