Quick Answer
What are WhatsApp Flows?
Flows are multi-screen interactive forms that open inside WhatsApp, so someone can complete a task - book a slot, submit details, choose options - without leaving the chat or opening a browser. You define them in Flow JSON, which describes each screen, its components and how navigation moves between them, with a limit of 50 components per screen. There are two kinds: static Flows, which follow fixed logic and need no backend, and endpoint-connected Flows, which call your server as the person moves between screens and must use encrypted request and response payloads. A published Flow cannot be edited directly - you revert it to draft, change it, and republish.
Last updated:
WhatsApp Flows, Explained
Every business that collects information over WhatsApp eventually hits the same wall. Buttons handle a choice. They do not handle a form. So you send a link, the person leaves the chat, and some fraction of them never come back.
Flows exist to close that gap: a real multi-screen form that opens inside WhatsApp itself. No browser, no redirect, no moment where the person has to decide whether your link is worth tapping.
How a Flow is put together
A Flow is described in Flow JSON — a schema defining each screen, the components on it, and how navigation moves between them. Meta renders it natively on the recipient’s device. You are not shipping HTML; you are describing an interface Meta draws.
Each screen supports up to 50 components, which is far more than any sensible screen should use. Treat that as a ceiling, not a target — a WhatsApp Flow shown on a phone in a noisy room is not the place for a forty-field form.
Static or endpoint-connected
This is the decision that determines how much work you have signed up for, and it is worth making deliberately. A static Flow is a configuration exercise. An endpoint-connected Flow is a service you now operate, with encryption, uptime and latency obligations attached.
The honest guidance: start static. A great many Flows that were specified as dynamic turn out to need only a fixed set of options, and the ones that genuinely need live data usually only need it on one screen out of five.
The encryption requirement is the real cost
If your Flow calls an endpoint, Meta encrypts the request and expects an encrypted response. Your server has to decrypt, process and re-encrypt on every screen transition.
This is not a line of middleware. It is key management, it is a failure mode you have to design for, and it is the reason endpoint Flows routinely take three times longer to ship than the estimate. It also has an unforgiving user-facing consequence: if your endpoint is slow or errors, the person is stuck mid-form inside WhatsApp with no good recovery path. The reliability bar is higher than for an equivalent web form, not lower.
The publish lifecycle catches teams out
A published Flow is immutable. To change anything you revert it to draft, edit, pass validation again, and republish.
For teams used to shipping web forms this is a genuine constraint rather than a formality. You cannot hot-fix a typo in a live Flow while people are using it. If a Flow is part of something with a fixed date, the testing has to happen before publish, because during is not available to you.
When a Flow is the wrong tool
The pattern to avoid is building a Flow because it is the most capable option rather than because the task needs it. If three reply buttons collect the same answer, they will collect it sooner, cost less to maintain, and never need reverting to draft.
Flows are worth the effort when the interaction is genuinely multi-step, when you need clean structured data from a lot of people, or when you can measure what sending them to a browser costs you. Those are real situations — they are just narrower than the feature list suggests.
Tools referenced in this post
Try Weddingkart for your wedding
Guest lists, WhatsApp invites, RSVPs, countdowns and more - the AI layer for Indian weddings.
Related reading
Frequently Asked Questions
What is the difference between a WhatsApp Flow and a link to a web form?
Mostly completion rate and context. A link takes the person out of WhatsApp into a browser, where they have to load a page, possibly log in, and finish on a screen that has nothing to do with the conversation they were having - and a meaningful share simply do not arrive. A Flow renders natively inside the chat, so the person never leaves, the interaction stays attached to the thread, and the answers come back to you as structured data rather than as a form submission you then have to reconcile with a phone number.
Do I need a backend to build a WhatsApp Flow?
Not for a static Flow. If the screens and options are known in advance - a fixed set of questions, a defined list of choices - you can define the whole thing in Flow JSON and Meta renders it with no server involved. You only need an endpoint when the content has to be decided at the moment the person is looking at it: live availability, personalised pricing, anything that depends on data that changes.
What are the security requirements for endpoint-connected Flows?
They are strict, and they are the main reason endpoint Flows take longer to build than people estimate. Your endpoint must decrypt the request Meta sends and return an encrypted response, so key handling becomes part of the implementation rather than an afterthought. It also has to be reliable and quick, because a slow or failing endpoint stalls the person mid-form with no useful way to recover.
Can I edit a published WhatsApp Flow?
Not directly. A published Flow is immutable - to change it you revert it to draft, make the edit, pass Meta’s validation again, and republish. Plan for this in your release process, because it means a live Flow cannot be hot-fixed the way a web form can. If a Flow is part of something time-sensitive, test it thoroughly before publishing rather than expecting to patch it during.
Are WhatsApp Flows worth building for a small number of responses?
Often not. A Flow is real engineering - JSON authoring, validation, a publish lifecycle, and encryption if it is endpoint-connected. For a handful of straightforward answers, three reply buttons will collect the same information at a fraction of the cost. Flows earn their keep when the interaction is genuinely multi-step, when you need structured data from many people, or when dropping someone into a browser would visibly cost you completions.
Was this article helpful?
Share
By Weddingkart TeamLast updated