Status messages webhook reference | Developer Documentation
Track a WhatsApp message's delivery through ChatArchitect
Use the sending tool's message history, or the webhook results of your own ChatArchitect integration, to follow a specific outgoing attempt. Keep the recipient, connected business number, attempt time and available message references together. A successful queue submission does not establish delivery.
Read the available result
| Result | Meaning for the attempt | Next check |
|---|---|---|
submitted | ChatArchitect accepted the send request into its queue. | Keep the response reference and look for the later result in the tool or webhook. |
sent | A sending event has been reported. | Continue checking for delivery; this event alone is not a device receipt. |
delivered | WhatsApp reported delivery to the recipient's device. | Keep this result against the same attempt; it does not establish that the customer answered. |
read | WhatsApp reported the message displayed in the recipient's client. | Use the read indicator guide to keep outgoing results separate from acknowledgements of incoming messages. |
failed | A sending or delivery failure has been reported. | Record the supplied reason and code when available before deciding what to change. |
Your CRM or help desk may display different labels or only some results. Check its documentation and the exact attempt rather than treating every local “sent” badge as a delivered message.
For your own API integration
The ChatArchitect API quick start documents the send response and webhook. Use that guide for the connection and callback setup. Its status event example uses the following fields:
| Field | Use |
|---|---|
status and messageId in the send response | Record the submitted request and its response reference. |
Webhook root type | message-event identifies a status event in the guide's example; an inbound customer message uses message. |
payload.type | The reported status, such as failed, sent, delivered or read. |
payload.id and payload.destination | Keep the webhook reference and reported destination for correlation with your records. |
payload.payload.reason | Keep the failure explanation when it is supplied for a failed event. |
Record both the synchronous messageId and webhook payload.id. The guide's examples contain different values, so they do not establish a universal equality rule between those fields. Verify your actual correlation in a permitted test and retain the tool/account context, destination and attempt time as well.
Process repeated events safely and preserve the observed history for that attempt. Keep the original event timestamp and your receive time separately, with a documented time zone and unit when converting values. Do not create another customer message merely because the same status event was received again.
Check incomplete or unexpected progress
Do not require a separate callback for every row in the table. Meta's status reference notes that a read event can imply delivery without a separate delivered callback in some cases. The absence of one intermediate event does not establish failure.
If you only have submitted, check the tool's later history or, for your own integration, the registered callback and event handling described in the API guide. Keep the outcome unresolved if there is no verified delivery result. Ask support about the original attempt before repeating it.
If the result is failed, use its actual explanation to check the relevant issue: the reply window, selected recipient/number or approved template. Do not translate an unfamiliar code into a Meta error by guessing. Use the sending-error diagnostic guide to locate the reporting stage and prepare the attempt evidence.
Keep status, incoming messages and charges separate
An incoming message that cannot be displayed needs a different check from an outgoing failed send; use the incoming message checklist. The Meta reference describes its own webhook schema. The field table above comes from the ChatArchitect guide and does not replace your tool's interface with Meta fields.
Use the ChatArchitect pricing guide for customer charges. A delivery label or an imported Meta pricing field alone is not a customer invoice.
For support, provide the tool or integration, connected number, recipient, attempt time with time zone, both available references, latest observed result and exact error. Keep App key and Secret out of the report.
No comments to display
No comments to display