Webhooks allow you to subscribe to events happening on the Didomi platform to implement custom workflows when your users change their consent preferences. When users make choices on your websites, mobile apps, or preferences center, you will receive a notification allowing you to react to user choices.
When an event is triggered, we'll send a HTTP POST payload to the configured webhook endpoint. Webhooks are configured at the organization level and automatically apply to all consent events triggered within your organization, on all websites, mobile apps, or preferences center.
Webhooks can be configured by reaching out to our support team. Provide the endpoint to send events to and, optionally, the OAuth credentials (client ID and client secret) to use.
To ensure that the consent events are received, when your endpoint is down, we retry at least five times during five minutes before moving on.
The Didomi servers will authenticate against your OAuth authorization server with a Client ID and a Client Secret that you provide to obtain an Access Token.
Didomi will then call your API endpoint for sending emails with the Access Token provided in the
Authorizationheader as a Bearer token.
API calls from Didomi will originate from the IP
184.108.40.206. You must whitelist that IP to allow traffic from it for emails to be sent.
Events sent to your HTTP endpoints are sent as JSON-encoded objects with the following information:
The payload is a JSON string in the body of the HTTP request. Examples:
Pending events (with status
pending_approvalor similar) are always sent as
However, new pending events only generate
user.createdevents if a new user is created as a result of a pending event. If a pending event applies to an existing user, a
user.updatedevent is not generated as the user is not effectively modified until the event becomes confirmed.
When a pending event becomes confirmed and, assuming it contains changes that effectively modify the status of the user, then and only then a
user.updatedevent is sent.