To ensure that the Web SDK is served from your own domain and infrastructure, we recommend setting up a reverse proxy. This ensures that the SDK and API requests are cached on your own servers while allowing you to use the latest version from the SDK and from the consent notice configuration.
The Web SDK is served on
sdk.privacy-center.org and is made of two different types of files:
Loaders with configuration: Dynamic files that contain the configuration of consent notices . Those files are updated every time you publish a new version of the consent notice in the Didomi Console. They have a short lifetime (from minutes to 1 hour).
Core and UI: Static files that contain all the logic and UI of the SDK. Those files are updated regularly when Didomi releases a new version of the SDK. They are usually marked with a version stamp and have a very long lifetime (up to 1 year).
We do not guarantee the number of files or the structure of their names as those can change pretty often as we update our SDK and optimize it. Do not try to cache specific files: all files from the
sdk.privacy-center.org domain should be proxied and cached without any filtering on your side.
The API is available on
api.privacy-center.org. All requests sent ot the API must be proxied to the domain without any caching.
To setup a reverse proxy, implement the following steps.
Create a dedicated sub-domain and point it to your reverse proxy. We'll use
dsdk.client.com as an example in this documentation but any sub-domain will work.
Configure the reverse proxy software of your choice with two rules to proxy:
All files from
https://sdk.privacy-center.org with their associated path, method, headers, and body. The proxy must query the Didomi URL in HTTPS.
For instance, the request
GET https://dsdk.client.com/loader.js?domain=... should be proxied to
All requests to
https://api.privacy-center.org with their associated path, method, headers, and body. The proxy must query the Didomi URL in HTTPS.
For instance, the request
POST https://dsdk.client.com/api/events should be proxied to
When proxying a request to the Didomi CDN, your proxy should be configured with the following rules:
Forward path and query-string
The full path and query-string of requests must be forwarded in entirety to the Didomi CDN. Caching must be done on the full path and query-string.
Do not forward cookies
Cookies should not be forwarded to the Didomi CDN and can be discarded from the request.
Forward user IP
The original IP of the user should be forwarded to the Didomi CDN in a
Cache based on geo
The Didomi CDN files are generated and served based on the user country. Ensure that your proxy acts the same way and caches different versions of a given file based on the country of the user request.
Files returned by the Didomi CDN are not specific to a given user but to the user country.
After getting a file from the Didomi CDN, your proxy must respect all cache headers returned by the Didomi CDN (Cache-Control, Expires, etc.) to ensure that files updated on the Didomi CDN get updated in your proxy as well.
You must return the cache headers to the end user as well to limit the number of requests sent by users to your proxy and the number of requests sent by your proxy to the Didomi CDN.
If your proxy is querying the Didomi CDN more often than indicated by the cache headers, it must include HTTP headers like
Etag from the cached files.
Files can be cached locally by your proxy and used if stale for increasing reliability.
Once your sub-domain and proxy are setup, the SDK needs to be configured to use your domain for three types of requests:
loader.js request that is sent directly from the Embed code obtained from the Didomi Console.
The chunks loaded by the SDK itself.
Requests sent to the API by the SDK.
The following steps explain how to configure the SDK.
Update the Embed code from the Didomi Console to replace
https://sdk.privacy-center.org/ with your sub-domain. This ensures that the first request to load the Didomi SDK (the
loader.js file) uses your sub-domain.
apiPath properties in the
sdkPath property must start with
//. It must also end with a final
apiPath property must start with
The following two limits apply when using a reverse proxy for serving the Didomi SDK.
When you publish changes to a consent notice with a the regular SDK domain, the notice is instantaneously updated on your website. The cache of the Didomi CDN is invalidated to ensure that the changes are immediate. With a reverse proxy, an additional delay is added as the cache of the proxy is not immediately cleared. Having a mechanism to clear the proxy cache after publishing a consent notice can help solve this problem.
To avoid doing HTTP requests to determine the user location, Didomi embeds the user country in the SDK files. The SDK files are served and cached based on the user country. If the reverse proxy correctly caches files based on the user country then that behavior will function as intended.
If the reverse proxy does not cache files based on the user country, all users will appear as being located in a single country (the one where the reverse proxy is located). This only impacts the country-based analytics and does not impact the correct behavior of the SDK or the consent management.