text is required — the Flow is a button, not the whole message. The flow block cannot be combined with templateId, list, carousel, buttons, header, or a direct media send.
The 24-hour window is not optional
This is the part you cannot see, and the reason we refuse the send instead of trying it. We measured this on 9 September 2026 against three versions of the Graph API — v22.0, v25.0 and v26.0 — with real numbers and real handsets. Outside the 24-hour window, Meta answersHTTP 200 with a wamid and silently discards the message. No error. No failure status. Nothing in any log. Eight sends, four delivered, 200 on all eight.
So if we let it through, your message would vanish and neither you nor we would ever know. Instead you get:
Errors
FLOW_NOT_SENDABLE returns one message for all three causes on purpose. Telling you “it exists, but it belongs to another account” would confirm that an id you do not own is real.
Getting the answers back
When someone submits the Flow, the answers arrive on theflow.response_received webhook event and in GET /v1/flows/{id}/responses, correlated with the send that produced them.
You do not have to do anything for that correlation to work. The token that links the two is generated per message and stored when the message goes out — which is also why flow_token in the request body is refused. A token chosen by the caller would let one account claim another account’s answers.
Subscribing to
flow.response_received is a separate step. See Flow responses.Two things worth knowing before you test
A Cloud API number does not receive Flows. Sending to another Meta number — even with the window open — does not deliver, and Meta still answers200. Test with an ordinary phone.
mode: "draft" works. You can try a Flow before publishing it. Remember the message reaches a real person.