Button messages webhook reference | Developer Documentation
Check replies to WhatsApp template buttons in ChatArchitect
If an approved WhatsApp template offers a reply button, decide how the customer's selection should appear in your CRM or application. Check the exact template, receiving route and supported response mapping before using the selection to create a task or change a customer's record.
The template component guide describes the buttons exposed in Submit template at wtargeted.com. Specific button types and their callback behavior still need confirmation for the intended integration. The ChatArchitect API quick start does not specify template-button reply callbacks or automatic CRM actions; ask support for the supported route and a redacted example.
Separate a reply selection from other button actions
Meta's button-message reference describes a customer tapping a quick-reply button in a template. Its provider event carries the reply and a reference to the message containing that button. This does not establish ChatArchitect's transformed callback, the available response identifier or how the connected tool displays the reply.
- Confirm that the selected button is intended to send a reply. A button that opens a website or starts a phone call is a different action; do not infer a quick-reply event from either.
- Record the original template message, the connected business account and the customer's conversation using the references supported by that route.
- Keep the displayed label distinct from any action identifier your confirmed contract provides. Translations and later label edits can otherwise change how your application interprets an answer.
- Distinguish a button selection from an ordinary text message with the same wording. Obtain a supported rule before assigning an automatic action.
This checklist concerns replies to template buttons. It does not define standalone interactive buttons or list replies. A received selection also does not establish completion of an appointment change, cancellation or other business operation.
Test the receiving path before enabling actions
- Confirm that a reply button and its receiving behavior are supported for your template and connected tool. Agree one harmless test outcome with the responsible operator.
- Select the approved template and language in the intended sending tool. Review the received content with the preview checklist.
- Send the permitted test to a person who agreed to receive it. Record the original send and any references exposed by the tool, then have that person use the intended reply button.
- Inspect the receiving tool or supported callback. Check the customer conversation, selected option, reply time and relationship to the original template message.
- Verify the proposed business action separately. Confirm that one selection produces the intended result once, including when the same event is processed again under the integration's supported duplicate rules.
- Check a different option and, where relevant, another supported language. Verify that a translated label or stale template selection cannot direct the reply to the wrong workflow.
Use the webhook overview and receiver checklist to separate receipt, parsing, display and action. Do not assume that the original send's messageId equals a reply reference or that a label is a unique customer identifier.
When the selection is missing or produces the wrong action
| Observed result | Next check |
|---|---|
| Button opens a site but no reply appears | Confirm the button type. A website action is not evidence of a missing quick reply. |
| Customer sees the reply; CRM has no selection | Confirm support for that connector, then inspect receipt, parsing and display independently. |
| Answer is attached to another task | Review conversation matching and the supported original-message reference before repeating the action. |
| Two tasks appear for one choice | Review duplicate handling and whether more than one automation processed the same event. |
| Label change breaks the action | Recheck the supported action mapping and changed template content. |
If the receiving route is not confirmed, arrange a clear text reply or an operator handover through the supported conversation path. Do not advertise an automatic button workflow until the selection and its result have been checked.
An unsubscribe reply needs a reviewed withdrawal process. Receiving that reply does not prove that every campaign list was updated or that a separate Meta marketing-preference event arrived.
For support, provide the connection, integration version, template name and language, button type/label, times and available original/reply references. Use redacted examples and the data-handling guide. See Meta's template-button reply reference for the provider format.
No comments to display
No comments to display