What Are WhatsApp Flows? Forms Inside the Chat, and a Publish Button You Cannot Fully Undo (2026)

Quick answer: A WhatsApp Flow is a form that opens inside the chat. Your customer taps a button in a message, a set of native screens slides up over the conversation, they pick a date or type an address or choose a plan, they submit, and the answers arrive as one structured payload instead of five messages your bot has to interpret. Meta ships this as part of the WhatsApp Business Platform, and its documentation refers to a Flow Builder interface in WhatsApp Manager, so a simple Flow does not have to start with code. The part almost nobody mentions is what publishing commits you to. Once published, a Flow cannot be deleted. Turning it off means marking it deprecated, and that cannot be reversed either. And if your Flow calls your own server for its data, Meta monitors that server: it can block the Flow entirely, or leave it opening normally while capping you at ten Flow messages an hour.

Two kinds of Flow, and the difference decides everything else

The word covers two builds with very different operational weight, and vendors rarely separate them on a pricing page. Meta does not name the two; static and endpoint-powered is our shorthand for a distinction its documentation draws by behavior.

A static Flow has all of its screens and options defined in the Flow's own JSON, uploaded to the Flow object ahead of time. A three-screen contact form, a fixed feedback survey, a sign-up with a known list of options. Nothing is looked up while the customer is filling it in, so no server of yours is involved until the submission arrives. Meta caps any uploaded Flow JSON at 10 MB, which is a very long way from anything an SMB will build.

An endpoint-powered Flow calls a server you run, mid-Flow, to decide what happens next. Meta's documentation is direct about the job that server does: it supplies dynamic data for the screens and it controls routing, so on each screen submission the Flow asks your endpoint for the name of the next screen and the data to render it. The endpoint can also tell the Flow to terminate, and can control whether a completion message is posted back into the chat. This is what you need for real availability, live pricing, stock, or anything personalized to the account.

That distinction is the single most useful thing to establish before a vendor conversation, because the second kind drags in requirements the first does not have. Meta's endpoint guide lists them plainly: an HTTPS server with a valid TLS certificate, an RSA key pair whose public half you upload for Meta to sign, and payload encryption you implement yourself. For Data API version 3.0, that scheme is a 128-bit AES key delivered under RSA-OAEP with SHA-256, the request body encrypted with AES-GCM, and the response encrypted back with the same key and an initialization vector whose bits you invert. Meta signs its requests with a SHA-256 signature in an X-Hub-Signature-256 header. If you cannot decrypt a request you are told to return HTTP 421; the same guide separately says that sending an appropriate response code in that situation is what forces the client to re-download your public key and retry.

How a Flow actually reaches somebody

There are two send paths, and they map onto the same distinction that governs every other kind of WhatsApp message: who spoke first.

Business-initiated. You attach the Flow to an approved message template using a button of type FLOW. The template goes through Meta's normal review, the button label is capped at 25 characters, and the Flow opens when the customer taps it. Everything our WhatsApp channel guide says about template approval and per-message billing applies unchanged, because this is a template message.

Customer-initiated. Inside an open conversation you send an interactive message of type flow with a call-to-action button. Meta advises keeping that button text to 30 characters or fewer and using no emoji. This path lives inside the 24-hour service window, which the channel guide covers along with what messaging costs on either side of it.

Both paths can carry a flow_token, optional in each and documented as defaulting to unused. Meta's endpoint documentation describes it as the equivalent of a web session identifier and gives "it should not be predictable" as its example of generating one by established best practice. On the customer-initiated path there is also a mode parameter, draft or published, which is how you send an unfinished Flow to a real phone for testing rather than to customers. Before any of this, Meta states two prerequisites for sending Flows at all: a verified business, and maintaining high message quality.

The publish button is close to a one-way door

This is the part that deserves the space, because it is the one operational fact that changes how you plan the work, and it is absent from most third-party explainers we have read.

Meta's Flows API reference documents five statuses. A new Flow starts as DRAFT and can only be sent with mode: draft for testing. You then publish it, and the reference states that a published Flow cannot be deleted or updated.

Editing is possible but it forks rather than overwrites. The publish documentation says you can edit a published Flow in future and return it to the draft state, which is why the send parameters let you choose mode=draft to send the current draft or mode=published to send the last published version. So the accurate way to put it is that the published version is immutable and the object is permanent, while your next revision lives alongside it until you publish again. The same reference offers a second route for a genuine variant rather than a revision: create a new Flow from an existing one with the clone_flow_id parameter.

Turning a Flow off is a separate and heavier action. Because a published Flow cannot be deleted, Meta gives you DEPRECATED instead: it makes the Flow impossible to send or open and lets you decommission the endpoint behind it. The reference says deprecated Flows cannot be deleted or restored to a previous state. That is the off switch, and it only turns one way.

The consequences are small but real, and they land on naming and hygiene. Drafts are still ordinary objects you can throw away, and Meta's documented way to test is to send a draft with mode: draft, so nothing forces you to publish an experiment. But every Flow you do publish stays in the WhatsApp Business Account for good, which means the name you gave it on a Tuesday afternoon is a name you will be reading in a list for years. Meta does document moving Flows between WhatsApp Business Accounts owned by the same business, up to 100 per request, with same-name Flows skipped — useful for an agency handing an account over, but a copy operation rather than a cleanup. And before you publish, Meta requires the same two things it requires before you send one at all, a verified business and high-quality messaging, plus a clean pass on validation and the publishing checks, plus adherence to its Flows design principles and compliance with WhatsApp's Terms of Service, the Business Messaging Policy, and the Commerce Policy where it applies.

Meta is watching your endpoint, and one of the penalties is quiet

The remaining two statuses are not ones you set.

Meta's reference gives the same trigger for both of the last two: monitoring detected that the endpoint is not working. BLOCKED is the loud version, where the Flow will not send and will not open. THROTTLED is the one to worry about, because it does not look like a failure. The Flow still opens, and only ten Flow messages an hour go out until the endpoint is fixed. Ten an hour is enough that a quiet Tuesday afternoon looks normal, and enough that a campaign silently stops working.

One published signal of endpoint health is a periodic check that Meta sends to your endpoint. Its decrypted payload is {"version": "3.0", "action": "ping"} and it expects {"data": {"status": "active"}} back, encrypted and returned like any other endpoint response. The documentation describes that check without stating that it alone determines the two statuses, so treat a failing ping as a strong candidate rather than as the whole mechanism.

A Flow's health also rolls up alongside three other nodes — your Meta app, the business portfolio, and the WhatsApp Business Account — each reporting AVAILABLE, LIMITED, or BLOCKED. Any of them can be the actual reason a Flow will not send, and the Flow node itself reads as blocked when an unpublished Flow fails a publishing check, which has nothing to do with an endpoint at all.

Two things follow for anyone not writing the code themselves. Ask a prospective vendor whether they surface Flow health status in their interface, because the health_status field exists in the API and a platform that does not read it will let you discover a throttle by noticing that Thursday was slow. And if your Flow is endpoint-powered, your form now has an uptime requirement, and whoever hosts that endpoint has an on-call obligation they may not know about. Our webhook entry covers the general shape of that problem; Flows are the case where one of the penalties is metered rather than binary. Agencies should also note Meta's instruction to Solution Partners to run a dedicated endpoint and encryption key pair for each WhatsApp Business Account they manage, which is a real cost multiplier for anyone planning to reuse one server across clients.

What Flows do not change

Three assumptions travel with this feature and none of them survive the documentation.

Flow categories are not pricing categories. Flows have their own categories field, and the eight values are SIGN_UP, SIGN_IN, APPOINTMENT_BOOKING, LEAD_GENERATION, CONTACT_US, CUSTOMER_SUPPORT, SURVEY, and OTHER. Those describe what the Flow is for. What a message costs is set elsewhere: by the template's own category, or by the message landing free inside the 24-hour service window, both of which our channel guide covers. You will read online that "Flows are sent as marketing messages." Nothing in the Flows documentation ties a Flow to a pricing category; the sample template-creation request happens to use MARKETING, and that is the whole basis for the claim.

They do not create permission to message anyone. A Flow is a payload rather than an entry point. Everything the channel guide says about opt-in applies before you can send the template that carries it.

They do not remove the need for conversation design. A Flow collects fields cleanly, which is exactly why the failure mode moves upstream: teams put the whole intake into one long Flow because it is technically easy, and people who would have dropped out of a chat drop out of a form instead. The judgment about how much to ask, when, and in what order is the one our multi-turn form design guide covers, and Flows do not make it for you.

What to ask before you buy

Four questions, in this order, asked while looking at the builder rather than the pricing page.

• Which plan tier includes WhatsApp Flows? Ask rather than assume. The one gate we have recorded first-hand is BotPenguin's, one step above its cheapest paid tier; we have not surveyed the rest of the market and cannot tell you where the norm sits.
• Static only, or endpoint-powered? If your use case needs live availability or real stock, ask specifically whether the builder supports endpoint-powered Flows, because that answer decides whether the platform is viable at all.
• Do you show me Flow health status? If the answer is a blank look, plan to be the monitoring.
• Show me a published Flow opening on a real phone. Not the preview. Meta's own documentation says the last screens display slightly differently for the end user and tells you to test on a mobile device before publishing. Note also that the shareable preview link Meta generates is public, needs no login, and expires after 30 days, so it is a stakeholder-review tool rather than a durable asset.

Chatbotscape earns affiliate commission on some of the platforms named below. It does not change what we publish. See our affiliate disclosure.

On platform support, we will say only what our own reviews recorded. BotPenguin is the one platform in our reviewed set whose review documents WhatsApp Flows explicitly, gated to its King tier at $99/month monthly-billed, which that review calls "a structurally rare capability at SMB pricing." Note that this is the gate for Flows specifically and not for WhatsApp itself, which the channel guide records as available on BotPenguin's entry band. The WhatsApp specialists in our set — Wati and AiSensy — and the multi-channel builders Manychat and SendPulse were not audited for Flows support at their last refresh, so treat their absence here as unverified rather than as a no, and check the current product pages. The ranked best WhatsApp chatbot list and the channel guide cover the rest of the buying decision, and the operational question of what to automate on WhatsApp at all is in our WhatsApp automation guide.

Related terms

• WhatsApp Business API — the platform Flows run on, and the template model they inherit.
• Lead generation chatbot — the use case LEAD_GENERATION names, and the one Flows are most often bought for.
• Conversational commerce — selling inside the thread, where a Flow is the checkout-shaped step.
• Webhook — the general version of the endpoint contract described above.
• Human handoff — what should happen when the form is the wrong answer.
• Chatbot analytics — where Flow submissions land, and who keeps them.

FAQ

What are WhatsApp Flows in simple terms?

Forms that open inside the chat. Rather than sending a link that takes someone to your website to book a slot or enter their details, you send a button; they tap it and a set of native screens opens over the conversation. They fill it in, submit, and you get the answers as one structured record. It is Meta's own feature, part of the WhatsApp Business Platform, and it exists because asking for six pieces of information one message at a time is slow for the customer and messy for the business.

Do I need a developer to build a WhatsApp Flow?

For a static form, often not. Meta's documentation refers to a Flow Builder interface in WhatsApp Manager and to Flows created through WhatsApp Manager, and the chatbot platforms that sell Flows generally wrap that in a builder of their own. For an endpoint-powered Flow you need a developer, and not only for the build: Meta's documentation requires an HTTPS server with a valid TLS certificate, an uploaded and Meta-signed public key, RSA-plus-AES payload encryption implemented on your side, and a health-check response. That is a service with an uptime obligation, not a form.

Are WhatsApp Flows free?

We found no separate Flows fee in Meta's Flows documentation, and Meta's pricing pages are the authority on that. The message that carries the Flow is billed like any other WhatsApp message, on the template's category rather than on anything to do with Flows. Your chatbot platform is the other cost, and where Flows are offered they are usually a paid-tier feature rather than an entry-tier one, though the only tier gate we have verified ourselves is BotPenguin's. Our channel guide has the per-message rate structure and the 24-hour service window that makes some sends free.

Can I delete or edit a WhatsApp Flow after publishing it?

You cannot delete it. Meta's Flows API reference is explicit that a published Flow cannot be deleted or updated, and that the alternative, marking it deprecated, cannot be undone either. Editing works but forks rather than overwrites: an edited published Flow returns to a draft state alongside the last published version, and the send parameters let you target either. For a genuine variant, Meta documents cloning into a new Flow. Plan naming and versioning accordingly, because everything you publish stays in the account list.

Why did my WhatsApp Flow stop being delivered?

If it is endpoint-powered, check its status before anything else. Meta's monitoring sets a Flow to BLOCKED when it finds the endpoint not working, at which point the Flow will not send or open, or to THROTTLED, where the Flow still opens but only ten Flow messages an hour can be sent. Throttling is the one that hides, because nothing errors and volume just drops. Meta's documented health check is a request whose decrypted payload is {"version": "3.0", "action": "ping"} expecting {"data": {"status": "active"}}, so an endpoint that answers anything else to an unfamiliar payload is worth ruling out. Note that the health rollup also covers your Meta app, the business portfolio, and the WhatsApp Business Account, so the Flow is not always the node at fault.

Is a WhatsApp Flow better than a link to my website form?

Sometimes, and the honest test is whether the friction you are removing is real. A Flow keeps the customer in the app and returns clean structured data, which is the common argument for it in markets where WhatsApp is the default way people talk to businesses. Against that: your website form can be changed in a minute, has no publish-permanence, and carries no throttle risk. For a booking or a qualification step inside a conversation that is already happening, the Flow usually wins. For a long application form that people arrive at from search, it usually does not. We publish no completion-rate comparison of our own, because we have not run one.

What is the difference between WhatsApp Flows and a chatbot flow?

Naming collision, and it causes real confusion in vendor calls. A chatbot flow is the branching logic your platform runs across a conversation. A WhatsApp Flow is a specific Meta object: a defined set of screens, with its own ID, categories, status, and lifecycle, that opens as a form over the chat. Most Flows are triggered from inside a chatbot flow, so you generally have both, and the sentence "we support flows" from a vendor means nothing until you ask which one.

Sources

• Meta. Sending a Flow, WhatsApp Flows documentation (page updated 16 June 2026) — the two send paths, the FLOW template button type with its 25-character label cap, the interactive flow message parameters including flow_message_version, flow_cta guidance of 30 characters and no emoji, flow_action of navigate or data_exchange, the draft and published mode parameter with its edited-Flow note, the optional flow_token defaulting to unused, and the business-verification and message-quality prerequisites. developers.facebook.com (read 6 August 2026).
• Meta. Implement endpoints for Flows, WhatsApp Flows documentation (page updated 28 June 2026) — the endpoint's role in supplying screen data and controlling routing, the HTTPS and TLS requirement, key-pair upload with Meta-side signing, the Data API 3.0 encryption scheme with its inverted response initialization vector, X-Hub-Signature-256 validation, the HTTP 421 decryption-failure code and the separate statement about an appropriate response code forcing a public-key refresh, the flow_token guidance, the health-check ping contract, the references to a Flow Builder interface and to Flows created through WhatsApp Manager, the instruction to Solution Partners to use a dedicated endpoint and key pair per WhatsApp Business Account, and Meta's own advice to avoid endpoint calls that are not needed. The page also documents a flow_token_signature JWT available from Flow JSON 7.3 and Data API 4.0, so the 3.0 encryption detail cited above is the widely deployed scheme rather than the newest one. developers.facebook.com (read 6 August 2026).
• Meta. Flows API, WhatsApp Flows reference (page updated 16 June 2026) — the eight Flow categories, the five status values with the statement that a published Flow cannot be deleted or updated and a deprecated Flow cannot be restored to a previous state, the ten-Flow-messages-per-hour throttle, the clone_flow_id parameter, the publish preconditions and policy references, the four-node health_status rollup, the 10 MB Flow JSON ceiling, the 30-day public preview link, the 100-Flow cross-account migration limit, and the note that the last screens display slightly differently for end users than in preview. developers.facebook.com (read 6 August 2026).
• Chatbotscape. WhatsApp chatbots — complete guide 2026. /channels/whatsapp-chatbot-guide — per-message pricing by category and country, the 24-hour service window, the 72-hour Click-to-WhatsApp free entry point, opt-in requirements, BSP markup, and the eight-platform comparison including BotPenguin's WhatsApp entry band. Not re-derived here.
• Chatbotscape. BotPenguin review. /reviews/botpenguin-review — the only Flows tier gate recorded in our set, at King tier, from vendor-page verification on 26 May 2026 and an authenticated pricing-page capture on 29 May 2026. The other fourteen reviews in our set were not audited for Flows support at their last refresh.
• Ahrefs Keywords Explorer, US and volume-by-country, 6 August 2026 — the search-demand figures in this entry's keyword note.
• Chatbotscape evaluation methodology. /methodology (continuously updated).