Generate a new WhatsApp Flow via the flows sub-agent
Builds a flow from a natural-language instruction — there is no hand-authored flow JSON path. Saves the JSON, records the flow, and drafts it on the connected WABA (never auto-publishes). Consumes credits.
A 200 does not mean the flow was built. The body is one of two shapes: the full result, or a bail-out { "success": false, "error": … } with none of the flow fields (the agent produced no flow, or the run was cancelled). Only a provider-level failure becomes 502. Check success and the presence of flow_name before reading the rest.
Note that success: false on the FULL shape means something narrower — the flow was saved, but Meta raised validation errors or a WABA copy failed. meta_validation_errors / user_waba_error tell you which.
Required scope: flows:write
Authorizations
Project API key issued in Settings → API keys. Send it as Authorization: Bearer pk_live_….
Headers
Target project id, for an MCP OAuth bearer (mcp_at_…) attached to more than one project — get ids from GET /v1/projects. Matched case-insensitively.
Omit it and a READ falls back to the connection's default project; a mutation (any non-GET) on a connection with 2+ projects is rejected with 400 project_required — a write is never defaulted to a guessed project. A connection with exactly one project never needs the header.
Scopes are checked against the SELECTED project only, never a union across the connection.
For a pk_ API key the header selects nothing — one key is one project's context — but it IS validated: omit it and the key's own project is used, send it and it must name that project, otherwise the call is rejected with 403 project_not_attached (a blank value is 400 invalid_project_header, as above).
Body
Natural-language description of the WhatsApp Flow to build.
1 - 5000