.svg?alt=media&token=8a6d8610-e43e-468c-a63a-6c3a9314e6f5)
Configuration by URL
Last updated
Last updated
This section describes how to override the configuration of the Didomi Web SDK through query-string parameters in the URL.
Configuration options should be done through the or through local configuration variables/files. Configuration by URL should only be used in .
Didomi allows some configuration properties to be passed via query-string parameters in the URL if you want to test or preview changes on the fly. The configuration passed in the query string is merged into the remote configuration (from the Console) and the local configuration (from window.didomiConfig).
For security reasons, we currently only allow the properties below:
notice.enable
notice.showDataProcessing
experiment.group
app.vendors.iab.version
You can either pass a full Didomi configuration object via a didomiConfig parameter or a specific attribute via didomiConfig.*.
To override more than one attribute, we suggest to use the didomiConfig parameter. It allows you to provide a full Didomi configuration object encoded as JSON. The format and content of the object is the same as the window.didomiConfig object added to a webpage so any option that can be passed there can be passed in the query string.
First, encode your configuration object as url-encoded JSON so that it can be read properly by the browser. You can use to convert your JSON object into a readable query-string parameter.
For example, { "notice": { "enable": false } } will become %7B%20%22notice%22%3A%20%7B%20%22enable%22%3A%20false%20%7D%20%7D and the URL will be:
If you want to override only one attribute, it may be faster and easier to use the didomiConfig.* parameter. It allows you to edit a specific attribute via a dot notation.
Use a dot notation to go deeper into the configuration tree. For example, { "notice": { "enable": false } } will be written as didomiConfig.notice.enable=false and the URL will be:
Configuration should never be passed via URL except for specific cases for temporary preview or testing. Here are a few cases where configuration via URL can be useful:
If you run AB test, it can be difficult to see how it looks on production, especially if the size of your test is small. To avoid you from clearing your cache and refreshing the page until you see the test configuration, you can force the test group to test or control.
Force your website to display the test group configuration :
In some cases, the notice might be displayed for a short time before being hidden in the WebView as the consent gets passed. To avoid that visual glitch, you can disable the notice in your WebView to make sure that it never shows:
If you want to transitioned to the TCF v2 and would like to have a preview on how it will impact your website, you can force the version via URL. The authorized values are 1 et 2.
Force your website to display the notice with a specific version of the TCF :
If you want to have a preview on how the data processing list will impact the UI of your notice, you can display it by switching showDataProcessing to true.
Force the data processing list to be displayed in the notice :
If you are opening WebViews in your mobile apps, you can . This allows you to not re-collect consent on the web pages.