Ctrlk
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Query user

You can query consent users that belong to your organization calling the GET /consents/users endpoint , and filter by user ID or organization user ID.

Paginate through users

Users are returned by pages of 100 and every query returns a cursor value that can be used to get the next page of results. You can iterate through pages of results by specifying the $cursor query-string parameter from the previous query. The returned cursor is null when there is no more result available.

Get the first 100 users that belong to an organization:

GET /consents/users?organization_id={organization_id}

RESPONSE
{
  "data": [
    ...list of 100 users
  ],
  "limit": 100, // Number of users in the current page
  "cursor": ... // Cursor to use for querying the next page of results
}

Get the following 100 users:

GET /consents/users
  ?organization_id={organization_id}
  &$cursor={cursor from previous query}

RESPONSE
{
  "data": [
    ...list of 100 users
  ],
  "limit": 100, // Number of users in the current page
  "cursor": ... // Cursor to use for querying the next page of results
}

Get a user by its organization user ID

The $merge_users query parameter aggregates the consent records of users with the same organizationUserId into a single object, providing a consolidated view of their unified consent status.

Get user's consent state for a given regulation

By default, user choices are registered under GDPR regulation.

For organizations managing users globally under various privacy laws, you can query the user's consent state for specific regulations by specifying it in the query-string parameter regulation (See all regulations supported by Didomi).

Include full configuration tree

The $include_full_tree query-string parameter provides enhanced functionality for building comprehensive user interfaces and analytics. When set to true, this parameter returns a complete representation of your organization's configuration tree merged with user consent data.

What this parameter provides

When $include_full_tree=true is included in your request:

  • Complete tree coverage: All purposes, preferences, and values from your configuration tree are included, even those for which the user hasn't made choices

  • Content information: Names and descriptions are included for purposes, preferences, and values when available from the configuration tree

  • Full value representation: The all_values property shows both checked and unchecked values, enabling complete reconstruction of the consent configuration

  • Hierarchical structure: Parent-child relationships are maintained through the parent_id property

  • Tree metadata: The config_tree property indicates which configuration tree was used

Example request

Enhanced response structure

With $include_full_tree=true, the response includes additional properties:

Key properties explained

  • from_tree: Indicates whether an item exists in your configuration tree (true) or was added from user consent data (false)

  • parent_id: Establishes parent-child relationships between items, allowing reconstruction of the nested hierarchy

  • all_values: Contains both checked and unchecked values, providing complete visibility into the consent configuration

  • config_tree: Metadata about the configuration tree used to build the response

The $include_full_tree parameter is rate-limited to ensure platform performance. See the Rate limiting documentation for details.

Status propagation

Consents API V2 does not support Status propagation. For Consents API V2, use One-click consent instead, which provides similar functionality through consent propagation at the purpose level.

Status propagation is a feature available in Consents API V1 (deprecated), where the user choice at a specific level automatically propagates to elements at the lower level.

For instance, if a user sets enabled to false at the purpose level, it overrides lower-level enabled values (for preferences and channels) that will also be set to false automatically.

A practical example is that enabled at the purpose level can be used to implement Subscribe to all / Unsubscribe to all features where a user can subscribe to / unsubscribe from all preferences (current and future) by setting enabled to false on the purpose. Future preferences under that purpose will automatically get enabled set to false.

For instance, if you are pushing the following consent status to the API:

This status from the event indicates that the user has disabled the purpose but enabled the preference. When updating the user status from the event, the status from the purpose will be propagated down to the preference and the API will store:

PreviousOne-click consent and user consent status
NextDisable integrations for users

Last updated