Worked request and response samples
Copy a request as written, substitute your own values, and compare the response envelope. The conversational-automation chain a WhatsApp admin runs: read the config → write the full desired state → re-read to verify. Every sample below pairs curl with raw Node and Python (fetch / requests) — the Node SDK’s client.request(method, path, body) escape hatch and the Python SDK take the same route shape.
Template sends live elsewhere. The loop for approved-template sends (GET /templates → POST /api/v1/messages/whatsapp) is worked end to end in API recipes, task 13. This overlay covers the operations on this page: the WhatsApp-specific config surface, interactive sends, and test-account analytics.
1. Read the conversational-automation config
GET /api/v1/whatsapp/conversational-automationprompts), and the slash-command menu (commands) — the same object you send back on update.
2. Update the config (full desired state)
PUT /api/v1/whatsapp/conversational-automationprompts clears the ice breakers rather than leaving them as they were. Owners and admins only. command_name must be lowercase letters, digits, and underscores (no spaces); the caps — at most four ice breakers of 80 characters each, at most 30 commands — are validated here, so a bad config returns a 422 before it reaches Meta.
Request
422 with the offending field in error.details — for example a command_name with a space or an upper-case letter:
422
3. Send an interactive message
POST /api/v1/whatsapp/messages/send-interactiveaction.buttons takes up to three reply buttons; the tap returns on your inbound webhook as button_reply. A list menu (action.button + action.sections) is the alternative shape.
Request
4. Test-account analytics KPIs
GET /api/v1/whatsapp/test-account/analyticsdaily holds up to 30 data points, oldest first.