Developers
Build on ConsentCook
One script tag puts the banner on a site. Everything it then serves — the published configuration, the cookie list, the signed record of each choice — is readable over plain HTTP, and the signatures can be checked without asking us for anything.
Install the banner
Paste this into the <head> of your site, before any tracking scripts. Your site key is on the site’s page in the dashboard.
<script src="https://consentcook.com/loader.js"
data-site="YOUR_SITE_KEY"></script>On WordPress and Shopify you do not need the snippet at all — the plugin and the app put it in place for you and keep the key in step.
Read a site’s published configuration
The banner fetches exactly one thing to decide what to show and what to hold back. It is public, it is signed, and you can read it yourself:
GET https://consentcook.com/config/<site key>.jsonThe response carries an x-cc-signature header over the exact bytes of the body. It is deliberately not cached for any length of time, so a change you publish is the change your visitors get on their next page view.
Check a consent receipt without trusting us
Every choice a visitor makes is recorded and signed with ECDSA P-256 at the moment it arrives. The public keys are published, so a receipt can be verified by anyone, offline, including against us:
GET https://consentcook.com/v1/public/receipt-signing-keysThat is the point of signing them. A consent record you can only check by asking the company that wrote it is not evidence of much.
What the signature proves, precisely: that we recorded this receipt, at that moment, and that nobody has altered it since. It does not by itself prove which visitor made the choice — a banner runs in the browser, and a browser cannot hold a secret. If you need a consent record that stands up to that objection, send it from your own server instead.
Send consent from your own server
The banner posts each choice for you, and for most sites that is the right answer. Where the record has to be defensible against someone arguing it was fabricated — a dispute, a regulator, an audit you expect to be challenged — post it from your backend instead and sign the body with your property’s ingest secret. Nothing in the page can produce that signature, so nothing in the page can forge a receipt.
POST https://consentcook.com/v1/public/consent-events
Content-Type: application/json
X-CC-Signature: <hex HMAC-SHA256 of the exact request body, keyed with your ingest secret>
{"schemaVersion":1,"receipts":[ ... ]}One property per request, and the signature is over the raw bytes you send, so compute it on the exact body rather than a re-serialised copy. Ask us for your ingest secret — it is not shown in the dashboard, because anything the dashboard renders can end up in a browser.
Connect an AI assistant
@consentcook/mcp is on npm. It speaks the Model Context Protocol, so an assistant that supports MCP can read your sites, scan results and consent records directly.
npx @consentcook/mcpIt authenticates with an API key. Keys are scoped, default to denying everything they are not granted, and are created in Developers in the dashboard — the one page named here that needs an account, because it shows your keys.
Questions and terms
For anything not covered here, get in touch. The security page sets out how the service is run, and the subprocessor list names everyone who touches the data.