smb_message_echoes webhook reference | Developer Documentation

Check WhatsApp Business app sends in ChatArchitect

When agents use the WhatsApp Business app and a connected ChatArchitect tool on the same number, agree how a message sent from the app should appear in the shared workflow. An agent who cannot see that reply in the CRM might send it again.

The coexistence guide describes keeping the app active. The ChatArchitect API quick start does not specify Business app echo callbacks, automatic conversation synchronization or edit/delete mapping. Confirm the supported behavior for the actual connection with support.

Identify a business send and its later updates

Meta's current message-echo reference covers messages sent by the business from the app or a linked device. It also describes edits and deletion of previously sent app messages, referencing the original message. These events provide platform context; obtain the ChatArchitect format before processing them.

• Check the connected business number, customer destination, source route and available original-message reference.
• Keep an observed business-app send distinct from an incoming customer message and from a new outbound request made by your application.
• An echo reports an existing app action. It is not an instruction to send the message again.
• Confirm how the receiving tool displays the app origin and whether agents can see enough context to avoid replying twice.

Do not run an incoming-message autoresponder merely because an app-send echo contains text. Use the direction and event mapping confirmed for ChatArchitect before triggering business actions.

Check visibility with a permitted conversation

1. Confirm that the business number uses coexistence and that the intended CRM or application receives app-send updates. Agree a test with the responsible agents.
2. Use a permitted personal test account to message the business number. Follow the first-message checklist and confirm the live conversation path.
3. Send a harmless reply from the Business app in the open service window. Record the time with time zone and check the reply on the recipient's phone.
4. Inspect the connected tool or supported callback separately. Verify the customer conversation, outgoing direction, text and available reference; check that the recipient received one reply.
5. If linked-device sends are supported for this route, check one separately. Confirm that the same message is not inserted again because more than one surface displays it.
6. For supported edit/delete updates, use a harmless approved test or redacted sample and verify that the update targets the original message. Review any task already created from its content separately.

The quick start's synchronous messageId belongs to an API sending attempt. Do not invent that API response for a message sent directly in the Business app. Confirm the reference mapping for each route using the webhook overview.

When the CRM misses or duplicates an app reply

If the connection does not expose app sends, agree one visible reply route or another clear team handover process. Confirm the recipient's observed result before resending a reply that appears absent from the CRM.

App-send updates are distinct from incoming customer corrections and from earlier history imports. Check each workflow's contract and business-action handling separately.

For support, provide the connection, integration version, source device/route, times, available references and whether duplication occurred on the recipient's phone or only in the CRM. Redact message content according to the data-handling guide. See Meta's app-send echo reference for provider details.