Skip to main content
ConstraintsThe same change can arrive as a singular or a plural event. Single-consent calls publish User Consent Accepted or User Consent Withdrawn. Bulk calls and the email consent-management link publish one User Consents Accepted or User Consents Withdrawn covering several consents. Handle both shapes.An accept or withdraw that does not change state publishes nothing — accepting a consent that is already active, or withdrawing one that is not active.User Consent Rejected is published on every reject call, with no state check. Rejecting an active consent deactivates it and publishes Rejected, not Withdrawn. A rejection of a consent the customer never accepted has UserConsentId: null.ConsentId means different things in the two shapes. In the singular events it is the consent version string {Key}_{Version}_{Revision}, and Id is the numeric consent version id. In the items of the plural events, ConsentId is the numeric id and ConsentVersionId is the string.
Published when a customer’s consent changes. Every payload carries CustomerId, equal to UserId. Timestamp is when the change happened.

Field reference

Field definitions match the user consent models used by the Consent endpoints. See Consent in the API Reference. The mobile app equivalents (/mobile-app/v1/UserConsents/activate, /activate/bulk, /withdraw and /reject) and the admin portal equivalents emit the same events. The consent-management page a customer opens from an email link emits User Consents Accepted, then User Consents Withdrawn, from one save. Customer sign-up emits User Consent Accepted for each consent the customer ticks, and User Consent Rejected for unticked consents configured to be rejected. PUT /v1/UserConsents/metadata emits no event.

Schemas

Last modified on October 7, 2026