1. Help Center
  2. Legal Requirements

How Didomi manages proof of consent

🔎 Didomi stores all your users' proof of consent. In order to do this, we store two different kinds of information:

  • the user's information
  • their individual proof of consent as well as the notice configuration at the time the proof of consent was obtained.

📆We keep this information for a period of 5 years. 

👉If you frequently need to obtain the proof of consent, our batch export feature allows you to receive information about consent on a daily basis, as we export and send all the information regarding user consent every day. You can read more about this feature in our 📰 documentation.

👉For specific requests from your users, you can use our Versions & Proofs feature, available from your Didomi Console.

👉Moreover, if the request comes from a supervisory authority, Didomi will be able to provide the individual proofs of consent of all of your users as well as the notice configurations for the domain that is being inspected. 

In this case, Didomi will take the following steps:

✅ We will do a complete export of our user consent base thanks to the API. 

✅ You will be able to retrieve the versions of the notices yourself through the API (only if you use the Didomi console to manage your notices).

This is the procedure we follow if you need to retrieve a user's proof of consent:

The user's information and individual proof of consent

We store the user's information thanks to a cookie which contains a user ID. We use this user ID to obtain the user's individual proof of consent. 

You can learn more about the cookies stored by Didomi in this article.

If a user asks for their proof of consent, they will need to retrieve their user ID. You can find in this article the steps to follow to obtain it.

Once you have it, go to your Didomi Console to access the Versions & Proofs feature. To do so, please read our dedicated article. Versions & Proofs allows you to generate all the information related to the proof of consent of a user.

  • id: unique ID of the event
  • type: event type
  • datehour: date and time of the event with format YYYYMM-DD-HH
  • timestamp: unix timestamp of the event (in milliseconds)
  • Datetime: date and time of the event with format YYYYMM-DD HH:mm:ss
  • Namespace: event namespace (sdk for SDK events)
  • Rate: sampling rate for the event (1/rate will give you the actual count)
  • apikey: API key of the event
  • source: source of the event
  • source.type: type of SDK (sdk-web, sdk-mobile or sdkamp)
  • source.domain: domain or mobile app ID
  • source.key: public API key
  • source.version: version of the SDK (if type is sdk-mobile)
  • user: user that generated the event
  • user.country: country of the user (two-letter ISO 3166 Alpha-2)
  • user.id: ID of the user
  • user.id_type: type of the user ID
  • user.agent: full user agent
  • user.agent_info.os_family: operating system
  • user.agent_info.os_version: version of the operating system
  • user.agent_info.browser_family: browser
  • user.agent_info.browser_version: version of the browser
  • user.agent_info.device_type: type of device (if type is sdk-web)
  • user.tcfv: version of the TCF
  • user.tcfcs: TCF consent string
  • user.token: user token
  • consent: consent status for the event
  • is_bot: whether the event is from a bot
  • parameters: parameters specific to the event
  • experiment: experiment (AB test) information
  • experiment.id: ID of the experiment the user was a part of
  • experiment.group: group that the user was a part of in the experiment (test or control)

This document will look something like this: 


The configuration of the consent notice at the time the proof of consent was stored

We also store all the different notice configurations starting from the creation date of the notice in the Didomi console.

⚠️ If you are not using the console to manage your notices and you are still using a local configuration file, Didomi does not store the notices' configuration versions. We recommend you to import your notices in the Didomi console in order to have all the different notice versions which you will be asked for in the event of a data protection authority check.

Because of this, you can obtain the configuration of a specific notice at the moment the user's proof of consent was collected. This will give you information on all the vendors, purposes, formatting, texts and more elements that were available on your notice when the user made a consent choice.


You can obtain the notice configuration directly through our API. You can consult how to do it in our API specifications.  You can use GET/widgets/notices/configs/{id} and use a specific notice configuration ID to retrieve that configuration, as shown in the image: 

You can also retrieve a specific deployment using our API. See the specifications here

Here is a list with the descriptions of some of the elements that appear in the configuration. It is not a comprehensive list. You can find more information in our API documentation.  

  • id: unique ID of the notices configuration
  • full_atp: whether the SDK uses the ATP vendors selected by Didomi (false) or if it uses the client’s ATP vendors selection (true)
  • enable_ignore_consent_before: whether consent must be recollected after a certain date
  • ignore_consent_before: the date after which consent must be recollected (if enable_ignore_consent_before is set to “true”)
  • text_mode: whether the notice is using a custom text or an approved text
  • negative_action: what negative action should be displayed in the notice
  • disagree_button_style: the style of the disagree button
  • country: the country that the consent notice belongs to
  • notice_deny_applies_to_li: configurable legal basis for “Disagree to all” in notice
  • preferences_deny_applies_to_li: configurable legal basis for “Disagree to all” in Preferences
  • app: main configuration
  • vendors: vendors (see 📰 documentation
  • iab: TCF-related configuration
  • restrictions: TCF restrictions (see 📰 documentation
  • enabled: whether the TCF integration is enabled or not
    • languages: languages (see 📰 documentation)
    • enabled: list of enabled languages
    • default: default language
      • content: content of the notice (see 📰 documentation)
      • daysBeforeShowingAgain: amount of days during which the notice would not be shown again after consent is collected (see 📰 documentation)
      • enable: whether the notice is enabled or not (see 📰 documentation)
      • position: format of the notice (bottom, popup, etc.) (see 📰 documentation)
      • preferences: preferences (purposes and vendors)
      • content: content of the popups (see 📰 documentation)
        • categories: purposes and categories
        • theme: theme (see 📰 documentation)
        • color: main color used by the SDK
        • linkColor: links color
        • font: font to display
        • buttons: button themes
        • css: custom CSS