Consent log

Every consent decision your banner captures — accept, reject, or a granular save-preferences click — is written to a durable, hash-chained log entry. This is the system of record you'd point a regulator or auditor at to prove a specific visitor consented (or didn't) at a specific time.

What gets recorded

Each entry is stored per site (cbid) with:

Note: Necessary cookies never appear as a toggle-able choice — they're always granted, since the site cannot function without them, and are recorded in every receipt as an "implied" purpose.

Querying the log

The log is queryable per site over a time range and returns the most recent entries first:

GET /api/v1/:cbid/consent/log?from=<ms>&to=<ms>&limit=<n>

limit defaults to 200 and caps at 1000. Results are newest-first. This is the same data source that backs audit export & receipts and the DSAR erase/export tools, which look a subject up by their stamp.

Tamper-evidence

Records are hash-chained: each entry's hash incorporates the previous entry's hash, so altering or deleting a historical record breaks the chain from that point forward. You can verify chain integrity for a site at any time:

GET /api/v1/:cbid/consent/verify

which returns { "valid": true | false }. A false result means the stored chain has been tampered with or corrupted — treat it as an operational incident.

Finding a specific visitor's record

If a visitor gives you their consent receipt ID (the stamp, typically surfaced to them after they interact with the banner), you can look up every record tied to it — this is the mechanism DSAR access/erasure requests use under the hood, and how the preference center resolves a subject.

Note: Consent-log reads require authentication in multi-tenant deployments — the log itself is never publicly readable, unlike the cookie declaration feed.

See also: Audit export & receipts · REST consent