Reaction messages webhook reference | Developer Documentation

Handle incoming WhatsApp reactions with ChatArchitect

A customer may add or remove an emoji reaction to a message sent by your business. Before using it in a CRM workflow, verify whether the specific ChatArchitect connection forwards and displays reactions and how it identifies the original message.

The ChatArchitect API quick start defines incoming text and outgoing-result examples. It does not specify reaction callbacks, reaction removal or automatic CRM updates. Ask support for the supported behavior and a redacted example before building a reaction handler.

Identify what the reaction refers to

Meta's direct event reference distinguishes the reaction event's own message reference from the original business message referenced by the reaction. It also describes removal with the emoji property omitted. Confirm how ChatArchitect represents these cases; an absent field in an unconfirmed format is insufficient to classify a removal.

• Match the connected business number, sender and original message reference together.
• Keep the original message text and its delivery result intact when showing a reaction.
• Preserve a reaction whose target cannot yet be matched for investigation under your data policy. Do not attach it to the latest message merely because it came from the same sender.
• Confirm how adding, replacing and removing a reaction are represented before updating the displayed state.

An emoji can be ambiguous. Do not use it alone as an approval, unsubscribe instruction or payment confirmation. Ask the customer for an explicit text reply when a business action requires a clear decision. Use the delivery-status guide for outgoing results; a reaction and a delivery-status event serve different purposes.

Verify display and removal with a small test

1. Identify the intended business connection and the exact CRM, help desk or custom application. Confirm incoming reaction support and the displayed behavior with support.
2. For a custom receiver, obtain the reaction reference, target reference and removal representation in the ChatArchitect contract. Confirm duplicate handling and ordering rules using the webhook overview.
3. Use a permitted personal test account to message the business number, then send a harmless business reply in the open service window. Follow the first-message checklist and record the original attempt separately.
4. React to that specific reply on the test phone. Compare what is visible on the phone with the received chat update or supported callback, including its target message.
5. Remove the reaction on the test phone and inspect the resulting update. If replacement is supported, test a change of emoji separately.
6. Record test times with time zone, available references and the displayed result at each stage. Confirm that processing a duplicate does not repeat a business action and that an unmatched event remains available for review.

The quick start does not establish a universal equality between the synchronous messageId and the callback payload.id. Obtain the correlation rule for your connection before matching a reaction to an outgoing attempt.

When a reaction is missing or attached incorrectly

If this route does not expose reactions, ask the customer to send the required response as normal text. For unavailable content, use the unavailable-message checklist. Diagnose missing callbacks with the webhook troubleshooting guide.

For support, provide the connection, integration version, test time and separate references for the observed event and intended target where available. Include a redacted sample and the display before/after removal; follow the data-handling guide.

See Meta's incoming-reaction reference for the direct platform interface. This checklist concerns receiving customer reactions; it does not establish support for sending reactions through ChatArchitect.