user_preferences webhook reference | Developer Documentation

Handle WhatsApp marketing preference changes in ChatArchitect

When a customer asks to stop marketing messages, make the request usable by every team or tool selecting that audience. Review requests received in WhatsApp or another contact channel; an absent preference callback does not establish permission to keep sending.

Use the audience permission guide to record the request, scope and affected workflows. The ChatArchitect API quick start does not specify marketing-preference callbacks, a subscription-control endpoint or automatic CRM audience synchronization. Confirm those capabilities and their scope with support before relying on them.

Identify the preference and the customer

Meta's current user-preferences reference covers stopping or resuming marketing messages. It distinguishes these changes from Interested/Not interested feedback in Offers and announcements, which does not trigger that event. An unsubscribe template-button reply is another receiving path; do not treat these interfaces as interchangeable.

• Record the business connection and the individual customer using the identifiers supported by the route.
• Keep a request to stop marketing separate from a delivery result, a contact deletion and closure of a support ticket.
• If the supported event lacks a phone number, use the confirmed identifier mapping. Do not put a business-scoped user ID into a phone-number field.
• Meta's reference may include a parent business-scoped identifier for identification. It does not apply the preference at that parent level; do not extend a preference to other users from that identifier alone.

The platform event does not establish which customer records ChatArchitect can match or which campaign lists an integration updates. Confirm the mapping and affected scope rather than inferring them from the Meta field names.

Apply a stop request to future audience selection

1. Record the source, time with time zone, customer/business association and what the person asked to stop. Assign an operator to resolve an ambiguous request without launching another marketing send.
2. Exclude the person from affected future campaigns in each CRM, sending tool and automation under your team's control. Check other lists that select the same recipient; one edited record does not establish that all workflows changed.
3. For a custom application, obtain a redacted supported preference example, identifier mapping, stop/resume meanings and ordering rules before automating the update. Use the webhook overview for receiver checks.
4. Check already queued or accepted attempts separately with the tool operator or support. A preference update does not establish cancellation of a message already accepted for delivery.
5. Review the recipient-selection result before the next campaign. Confirm that duplicate processing or a delayed earlier event cannot silently restore an outdated preference.

A stop request is not a failed-delivery retry instruction. Use the delivery-status guide for actual sending outcomes and avoid bypassing the request through another campaign or sending route.

Review a later request to resume

Check the identity, business, source and time of the later request before changing the recorded preference. Review its scope alongside the planned marketing message and existing permission record. Resuming marketing is not automatic permission for unrelated communication or a reason to re-add the person to every saved list.

Use the supported ordering rule when an earlier stop arrives after a newer resume. If identity or sequence cannot be established, keep the affected campaign exclusion in place while the responsible operator resolves it. Confirm the final audience decision in each affected tool.

When the account, events and campaign list disagree

For support, provide the connection, receiving tool, source/time of the request, available identifiers, affected campaign and the expected audience change. Share test details or a redacted sample following the data-handling guide. See Meta's marketing-preference reference for provider definitions; confirm ChatArchitect's event delivery and audience behavior independently.