Events

A consent event is a partial update to the consent status of a user. When a user makes consent choices through a Didomi SDK (a consent notice, for instance) or through your own custom UI, you should create a new consent event on the Didomi platform. The user consent status will be automatically updated and the history of consent events will be kept, associated with the user.

The /consents/events endpoint of the API exposes the events managed by Didomi for your organizations. For a full reference of the endpoint and the resources that it returns, visit https://api.didomi.io/docs/.

Create a consent event

When a user gives consent to a set of purposes or vendors, create a consent event to register the user choices by calling the POST /consents/events endpoint.

A consent event consists of a set of partial choices from a user that will be merged into the user consent status. You can also send additional user information like a new ID or custom metadata. When pushing consent events, you do not need to know the prior consent status of the user and the consent information you are pushing will be automatically merged into the user consent status of the Users endpoints.

Example

A user giving consent to the purpose "purpose_id":

POST /consents/events?organization_id={organization_id}
BODY
{
"user": {
"organization_user_id": "user@domain.com",
"metadata": {
"custom_key": "value"
}
},
"consents": {
"purposes": [
{
"id": "purpose_id",
"enabled": true
}
]
},
"proofs": ["base64-encoded
}

You can specify either the user.organization_user_id field with your own organization user ID or a user.id field with the Didomi user ID. If you do not specify any user ID, a random ID will be automatically created for the user.

See the API documentation for more details on this endpoint.

Proofs

If you are collecting physical proofs of consents from your users (signatures, forms, etc.), you can attach them to the created events. Add your files as base64-encoded data URIs in the proofs property:

POST /consents/events?organization_id={organization_id}
BODY
{
"user": {
"organization_user_id": "user@domain.com",
"metadata": {
"custom_key": "value"
}
},
"consents": {
"purposes": [
{
"id": "purpose_id",
"enabled": true
}
]
},
"proofs": [
{
"filename": "proof.png",
"file: "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUAAAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO9TXL0Y4OHwAAAABJRU5ErkJggg=="
}
]
}

Files must be smaller than 10mb and their type must be one of the following formats: PDF, PNG, JPG, GIF, DOCX, DOC, MSG. You can attach a maximum of 5 proofs per event.

Pending events and approval process

By default, created events are confirmed: their status property has the value confirmed. This indicates that the event is valid and was applied to the user consent status.

Didomi supports various approval methods (email confirmation, email approval, etc.) where an event needs to be approved in a separate process before being applied to the user consent status. Such events are considered "pending" as they are created and stored in the API but not applied to the user consent status until the event is approved. Their status property is set to pending_approval.

To approve such events, one must update the event and set the status property to confirmed. In most cases, this approval process is handled by Didomi that also takes care of updating the event status. In the event you are managing this approval process yourself and need to update the status, you can do so with a regular PATCH

Example

PATCH https://api.didomi.io/v1/consents/events/{event_id}?organization_id={organization_id}&organization_user_id={organization_user_id}
{
"status": "confirmed"
}

When an event is updated to become confirmed, the Didomi API will automatically update the user consent status to apply the updated event. Events will be re-applied according to their update or creation date so that the most recents confirmed events will be applied last.

Delegates

Delegates are third-parties that modify the consents for an end user and that you want to keep track of. They can be an internal team or user that have been given access to the Didomi API. The third-party is a "delegate" who is doing modifications on behalf of the end user. Delegate information is optional and can be added to the event to keep track of the modification and its source for audit purposes.

Provide the delegate property when creating a consent event to indicate that the event was created by a delegate. You can specify the ID and name of the delegate, and use a generic metadata field to keep track of extra information on the delegate.

Example - Tracking an internal employee ID and their department when an event is created

POST /consents/events?organization_id={organization_id}
BODY
{
"user": {
"organization_user_id": "user@domain.com",
"metadata": {
"custom_key": "value"
}
},
"consents": {
"purposes": [
{
"id": "purpose_id",
"enabled": true
}
]
},
"delegate": {
"id": "<Internal ID to identify the delegate>",
"name": "<Name of the delegate>",
"metadata": {
// Custom metadata of the delegate
"department_id": "...",
"country": "..."
}
}
}

Delegates can also be used with consent tokens.

Query consent events

You can query consent events for a user by calling the GET /consents/events endpoint.

You must specify either the organization user ID (organization_user_id query-string parameter) or the Didomi user ID (user_id query-string parameter) of the user that you are querying events for.

Example

GET /consents/events?organization_id={organization_id}&organization_user_id={organization_user_id}
RESPONSE:
{
"data": [
{
"id": "00b89328-e3d5-4068-b346-8f4fcb4618df",
"user": {
"id": "a3722cd3-f2e4-4451-a564-83f5e8921449",
"metadata": {
...custom user metadata
}
},
"consents": {
"purposes": [
{
"id": "purpose_id",
"enabled": true
}
]
}
}
]
}

See the API documentation for more details on this endpoint.

Pending events

By default, the GET /consents/events endpoint only returns confirmed events. To get pending events, you must specify a status filter in the query-string parameter.

For instance, to get all confirmed and pending events, you would do:

GET /consents/events?organization_id={organization_id}&organization_user_id={organization_user_id}&status[$in]=confirmed&status[$in]=pending_approval
RESPONSE:
{
"data": [
{
"id": "00b89328-e3d5-4068-b346-8f4fcb4618df",
"user": {
"id": "a3722cd3-f2e4-4451-a564-83f5e8921449",
"metadata": {
...custom user metadata
}
},
"consents": {
"purposes": [
{
"id": "purpose_id",
"enabled": true
}
]
}
}
]
}

See the API documentation for more details.

Specific event

You can also query for a specific event by ID by calling GET /consents/events/:id. See the API documentation for more details.

Delete consent events

You can delete consents events by calling the DELETE /consents/events endpoint.

When deleting consent events, the user consent status will be automatically re-computed by re-applying the remaining (non-deleted) consent events.

You must specify either the organization user ID (organization_user_id query-string parameter) or the Didomi user ID (user_id query-string parameter) of the user that you are querying events for.

You must also specify a list of filters as key-value pairs in the query-string parameters to select consent events that should be removed. The key should be a property name from the Event Schema with nested properties path specified with a .. For instance, a custom event metadata field can be specified as metadata.custom_key.

Example

DELETE /consents/events?organization_id={organization_id}&organization_user_id={organization_user_id}&metadata.booking_id={booking ID}

See the API documentation for more details on this endpoint.

You can also delete a specific event by ID by calling DELETE /consents/events/:id. See the API documentation for more details.

Event Schema

The full schema of Events is as follows:

{
/**
* Unique event ID
*/
id: 'string',
/**
* Creation date of the event
*/
created_at: 'ISO8601 date',
/**
* Free-form metadata object
*/
metadata: Object,
/**
* User information
*/
user: {
/**
* Didomi user ID
*/
id: 'string',
/**
* Organization user ID
*/
organization_user_id: 'string',
/**
* Free-form metadata object
*/
metadata: Object,
},
/**
* IDs of proofs associated with this event
*/
proofs_id: [ ... ],
/**
* Delegate that created the event
* `null` if there is no delegate
*/
delegate: {
/**
* Unique ID of the delegate
*/
id: 'string',
/**
* Name of the delegate
*/
name: 'string',
/**
* Free-form metadata object
*/
metadata: Object,
},
/**
* Validation information (if the event was validated)
* `null` if there is no validation
*/
validation: {
/**
* Validation type used for this event
*/
type: 'email|signature|file'
},
/**
* Status of the event
*
* "confirmed" indicates that the event has been validated or was not subject to validation
* "pending_approval" indicates that the event is pending validation
*/
status: 'confirmed|pending_approval',
/**
* Consent status of the user
*/
consents: {
/**
* Purposes that the user has made choices for
*/
purposes: [
{
/**
* Unique purpose ID
*/
id: 'string',
/**
* Whether the user has given consent to this purpose or not
* A null value indicates that the user has not made a specific
* choice for the purpose but might have made choices for
* preferences or channels
*/
enabled: boolean | null,
/**
* Extra preferences expressed for the purpose
*/
preferences: [
{
/**
* Unique preference ID
*/
id: 'string',
/**
* Whether the user has enabled this preference or not
* A null value indicates that the user has not made a specific
* choice for the preference but might have made choices for
* channels
*/
enabled: boolean | null,
/**
* Channels
*/
channels: [
{
/**
* Unique channel ID
*/
id: 'string',
/**
* Whether the user has enabled this channel or not
* A null value indicates that the user has not made a specific
* choice for the channel
*/
enabled: boolean | null,
}
],
/**
* Free-form metadata object on the preference
*/
metadata: Object,
}
]
},
...
],
/**
* Vendors that the user has made choices for
*/
vendors: {
/**
* List of vendor IDs that the user has given consent to
*/
enabled: ['string', ...],
/**
* List of vendor IDs that the user has denied consent to
*/
disabled: ['string', ...]
}
}
}