Cross-Domain Consent

Cross-domain consent sharing lets visitors carry their consent preferences across different top-level domains (e.g. brand.com and brand.de) without requiring them to consent again.

How it works

Browsers enforce the Same-Origin Policy, so cookies set on brand.com cannot be read by brand.de. CookieBoss solves this with server-side consent records and automatic link decoration:

1. Visitor consents on brand.com → consent is POSTed to the sync API → a one-time consent_token is returned
2. Links to group domains (e.g. brand.de) are automatically decorated with ?_cb=TOKEN
3. On page load of brand.de → the script detects the _cb parameter → fetches consent from the sync API → applies it locally → cleans the URL

This approach is privacy-first: no third-party cookies, no iframes, no fingerprinting. It works in all browsers including Safari with ITP.

Setting up a consent group

1. Create a consent group

In your CookieBoss dashboard, go to Consent Groups and click New Group. Give the group a descriptive name, e.g. “Brand Europe”.

2. Add sites to the group

Open the consent group and click Add Sites. Select the domains you want to share consent between. You need at least two sites in a group for cross-domain sync to activate.

3. Publish all sites

After adding sites to a group, re-publish each site so the compiler injects the cross-domain config into the consent script. The compiled script will include:

• consentGroupId — identifies the consent group
• consentGroupDomains — list of all domains in the group
• consentSyncEndpoint — the API endpoint for consent token storage

How link decoration works

When a visitor makes a consent choice, CookieBoss:

1. POSTs the consent state to api.cookieboss.io/api/v1/consent-sync
2. Receives a cryptographically random consent_token (32 bytes, base64url)
3. Stores the token in localStorage under key cookieboss_ct
4. Finds all <a> links on the page that point to other group domains
5. Appends ?_cb=TOKEN to each link

A MutationObserver watches for dynamically added links (SPA support).

How token retrieval works

When a page loads on a group domain with a _cb URL parameter:

1. The token is extracted from the URL
2. The URL is immediately cleaned (the _cb param is removed via history.replaceState)
3. The consent state is fetched from api.cookieboss.io/api/v1/consent-sync/:token
4. Consent is applied locally (cookie + localStorage)
5. The consent banner is skipped; only the floating trigger button is shown

Token lifecycle

• Tokens are valid for 5 years (matching the consent cookie expiry)
• If a visitor updates their consent preferences, the existing token is updated (PUT)
• Expired tokens are automatically cleaned up by a server-side cron job

API endpoints

The consent sync API is public (no authentication required) with CORS origin: *:

Method	Endpoint	Description
POST	/api/v1/consent-sync	Store consent → returns { token }
GET	/api/v1/consent-sync/:token	Retrieve consent for token
PUT	/api/v1/consent-sync/:token	Update consent for token

POST body

{
  "groupId": "01HXYZ...",
  "categories": {
    "necessary": true,
    "analytics": true,
    "marketing": false,
    "functional": true
  }
}

GET response

{
  "categories": {
    "necessary": true,
    "analytics": true,
    "marketing": false,
    "functional": true
  },
  "consentedAt": "2026-03-05T10:30:00.000Z"
}

Privacy considerations

• No third-party cookies or iframes are used
• Consent tokens are random, non-identifiable, and cannot be correlated back to a user
• URL parameters are cleaned immediately after processing
• The sync endpoint does not log IP addresses or user agents
• Tokens expire and are automatically purged