Dynamic WhatsApp Flows: live data inside the chat
A dynamic WhatsApp Flow behaves like a small, live application inside the chat. Where a static flow ships its whole definition up front, a dynamic flow calls a live endpoint on your instance at each step, so its screens are built from your own data at the moment the customer opens them. Think of a booking flow that shows the appointment slots that are actually free right now, an order-status lookup, or an account screen — anything that can't be baked in ahead of time.
This is the advanced tier of Flows. It's genuinely useful for a narrow set of cases and unnecessary for the rest, so the honest advice is: keep forms static unless they truly need live data.
How it works
When a customer interacts with a dynamic flow, WhatsApp sends an encrypted request to a public endpoint on your instance. Your instance decrypts it, works out which screen and data to return, and responds — encrypted — with the next screen and its data. This exchange repeats for each step until the flow completes.
Because the endpoint is public and handles live data, security comes entirely from encryption. Your instance holds an RSA key pair: the private key is stored encrypted at rest and never leaves the server or reaches the browser, and the public key is registered with WhatsApp for your sender. Each request carries a one-time AES key wrapped with your public key, which your private key unwraps to decrypt the payload; the reply is encrypted with the same key. You generate and register these keys from Settings → WhatsApp Flows, and a flow can't be published as dynamic until its sender has a registered key.
What the endpoint does
The endpoint answers a small set of actions. A health-check ping confirms it's alive. An initial request returns the first screen and its data. A data-exchange request — sent when the customer submits a screen — is where your instance runs any lookup it needs (live availability, contact fields, a catalogue) and returns the next screen, or completes the flow. Each step's state is held server-side so the conversation stays consistent. The final answers still arrive over the ordinary inbound webhook and land in the flow's Responses tab, exactly like a static flow.
The trade-off to understand
A dynamic flow makes your endpoint's uptime load-bearing. Meta health-checks it and will throttle or block a flow whose endpoint is slow or unavailable, so a dynamic flow is only as reliable as the instance behind it. Static flows have no such dependency — they render entirely from the definition WhatsApp already holds. That's why the recommendation is to reserve dynamic flows for the cases that genuinely need live data and keep everything else static.
Getting started
Build a dynamic flow the same way as a static one, then mark the screens that need live data as data-exchange, enable images and data bindings where you want them, and point each dynamic screen at its data source. Generate and register your keys first, publish, and test the ping and a data-exchange step before sending it to real customers.
Frequently asked
When do I actually need a dynamic flow?
Only when a screen must show data that doesn't exist until the moment the customer opens the flow — live appointment availability, an order status, an account lookup, a catalogue that changes. Everything else should stay static, which needs no endpoint, keys or uptime.
What are the encryption keys for?
WhatsApp encrypts every request to your endpoint. Your instance holds an RSA key pair: the private key stays encrypted at rest and never leaves the server, and the public key is registered with WhatsApp for your sender. Each request uses that key pair to exchange a per-message AES key. You generate and register keys in Settings → WhatsApp Flows.
What happens if my endpoint goes down?
Meta health-checks the endpoint and will throttle or block a dynamic flow whose endpoint is slow or failing. That's the main reason to keep simple forms static — a static flow has no such dependency.
Do dynamic flow answers arrive the same way?
Yes. The final submission still arrives over the same inbound webhook as a static flow and lands in the flow's Responses tab, mapped to the contact.
Apply this to your own deployment
This guide describes decisions we make on live instances. Tell us your channels, systems and region and we will map it to an architecture outline, a provisioning plan and an indicative commercial model — usually within one business day.