Console: Sites & API keys
Create sites, add domains, and manage publishable and secret keys.
Sites
A site is the unit everything else hangs off — its domains, purposes, API keys and vault. Give each product or brand its own so their consent data, and their test/live traffic, never mix. The slug appears in API paths and is globally unique. A site is multi-domain: verified domains form the Origin allowlist for pk_ keys.
Deleting a site. A site that holds any subject — in test or live — can’t be deleted, only disabled: its consent history is evidence and stays intact. Only a site with no subjects can be deleted, which also removes its domains, keys and purposes.
Verify a domain
A domain you add works right away with TEST keys. LIVE keys, LIVE cookie scans and double opt-in redirects only accept it once you prove you control it. Click verify next to the domain and publish one of these:
- a DNS TXT record at
_croombit.<your-domain>with the valuecroombit-verify=<token>, or - a file at
https://<your-domain>/.well-known/croombit-verify.txtcontaining that same value.
Then click Verify now. Verifying example.com also covers www.example.com and every other subdomain. We re-check verified domains every week, and a domain whose record has been gone for three checks in a row drops back to unverified (it is recorded in the audit log). IP addresses and single-word hosts can’t be added. Over the API: POST /admin/sites/{siteId}/domains/{domainId}/verify, or the MCP tool verify_domain.
API keys
Two key types match the two places consent actually gets recorded from: your visitor’s browser, and your own backend.
| Type | Prefix | Use | Scope |
|---|---|---|---|
| Publishable | pk_test_ / pk_live_ | Browser (SDK) | Write/read consent for the referenced subject. Origin-restricted. No admin. |
| Secret | sk_test_ / sk_live_ | Server | Full site scope. Create subjects, merge, history, DSAR. |
- The full key is shown once at creation.
- Rotate mints a replacement; the old key stays valid until you revoke it (grace window).
- Revoke invalidates the key immediately.
- A
pk_key with no Origin allowlist returns403— add a domain to the site first.
Restricting a secret key
Secret keys can be narrowed down when you create them. None of these apply to publishable keys, which run in browsers everywhere and already have a fixed, public-safe surface.
| Scope | Allows |
|---|---|
consent:write | Record consent and preferences; request double opt-in confirmations. |
subjects:read | Read a subject, its consent, history and preferences, plus the TCF / Consent Mode / GPP signals derived from them. |
subjects:write | Create subjects, attach identifiers, merge subjects. |
dsar:write | Open data-subject requests. |
scans:write | The cookie-scanner worker: poll scan requests and submit results. |
- Scopes. A key with no scopes has full access, which is the default, so existing integrations keep working. A key with scopes gets
403 insufficient_scopeon anything else. Each/v1operation in the API reference lists the scope it needs (x-croombit-scope). - IP allowlist. Addresses or CIDR blocks (
203.0.113.0/24,2001:db8::/32). Calls from anywhere else get403 ip_not_allowed. IP-restricted keys are refused by the edge read endpoint; use the API instead. - Expiry. Optional. After the date the key gets
401 key_expired. A rotated key keeps its predecessor’s expiry.
apiKeyId. See Troubleshooting.