Webhooks

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.

Configuration

Webhooks can be configured from the Didomi Marketplace. Once enabled, go to the Manage sub-section under the Marketplace to configure your webhook.

Didomi Marketplace

Alternatively, you can reach out to our support team if you need further assistance. 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.

After the maximum amount of retries is reached, the event is placed in a permanent storage for later processing.

Authentication

OAuth Access Token

Requests sent to your API endpoint can be authenticated via OAuth Client Credentials grant.

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 Authorization header as a Bearer token.

IP address

API calls from Didomi will originate from the IP 35.159.1.63 . You must whitelist that IP to allow traffic from it for emails to be sent.

Payload

Events sent to your HTTP endpoints are sent as JSON-encoded objects with the following information:

Field
Description
type

Event type

The type of event.

string

Parameters

Entities affected by the event.

object

Events

Type

Description

Parameters

event.created

A new consent event has been created

event.updated

An existing consent event has been updated

  • source

  • old_entity: Event before it gets updated

  • new_entity: Event after the update

event.deleted

An existing consent event has been deleted

user.created

A new user has been created

  • entity: Created User

user.updated

An existing user has been updated

  • source: Event that triggered the User update (if any)

  • old_entity: User before it gets updated

  • new_entity: User after the update

user.deleted

An existing user has been deleted

entity: Deleted User

The payload is a JSON string in the body of the HTTP request. Examples:

{
  "type": "user.updated",
  "parameters": {
    "source": {
      "id": "unique_event_id",
      "created_at": "2019-08-07T10:45:11Z",
      ...
    },
    "old_entity": {
      "id": "didomi_user_id",
      "organization_user_id": "organization_user_id",
      ...
    },
    "new_entity": {
      "id": "didomi_user_id",
      "organization_user_id": "organization_user_id",
      ...  
    }
  }
}
{
  "type": "event.deleted",
  "parameters": {
    "entity": {
      "id": "deleted_event_id",
      "created_at": "2019-08-07T10:45:11Z",
      ...
    },
  }
}

Filters

You can customize which events your webhook will receive by selecting the desired event types in the Didomi Marketplace. If no event types are selected, the webhook will receive all available events by default.

Flatten request body

By enabling this option in the interface, your webhook payload will be transformed into a flat JSON object, simplifying property mapping depending on your webhook use case. Flattening converts a JSON object into a flat key-value format, where each key represents a property in the original JSON using a double underscore (__) as a separator. Currently, only the entity and new_entity properties are flattened, merging into a single entity property for simplicity.

Example

// event.created (original)
{
  "type": "event.created",
  "parameters": {
    "entity": {
      "organization_id": "didomi",
      "user": {
        "id": "some_unique_id",
        "organization_user_id": "[email protected]"
      },
      "consents": {
        "purposes": [
          {
            "id": "geo_location",
            "enabled": true
          },
          {
            "id": "market_research",
            "enabled": true
          }
        ]
      }
    }
  }
}
// event.created (Flattened)
{
  "type": "event.created",
  "parameters__entity__organization_id": "didomi",
  "parameters__entity__user__id": "some_unique_id",
  "parameters__entity__user__organization_user_id": "[email protected]",
  "parameters__entity__consents__purposes__geolocation_data__enabled": true,
  "parameters__entity__consents__purposes__market_research__enabled": true
}

Pending events

Pending events (with status pending_approval or similar) are always sent as event.created webhooks.

However, new pending events only generate user.created events if a new user is created as a result of a pending event. If a pending event applies to an existing user, a user.updated event 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.updated event is sent.

Last updated