JavaScript API
- Written for
- + Written for
- Deprecated
- + Deprecated
- Applies to
- + Applies to
JavaScript API
Once consent.js has bootstrapped (see embed scripts), it assigns a single global object, window.CookieMunch, and — for drop-in Cookiebot compatibility — also assigns window.Cookiebot to the exact same object (not a copy). Either name works everywhere in this page; internally the embed calls it CookieMunchApi (buildPublicApi() in packages/core/src/sdk.ts).
// Read the current consent snapshot
const state = CookieMunch.consent;
// → { necessary: true, preferences: false, statistics: true, marketing: false,
// personalizedAds: false, basicAds: true, adProfiling: false,
// adMeasurement: true, stamp: 'a1b2c3...' }
// Gate your own code on a category
CookieMunch.onConsentChange((state) => {
if (state.statistics) loadAnalytics();
if (state.marketing) loadAdPixel();
});
// Open the banner, or the granular preference center
CookieMunch.show();
CookieMunch.showSettings();
// Revoke consent and re-block previously activated tags
CookieMunch.withdraw();consent is a getter property, not a function — read it as CookieMunch.consent, never CookieMunch.consent(). This, and everything else below, matches Cookiebot's API shape on purpose so existing integrations port with a tag swap.
Properties
Property | Type | Description |
|---|---|---|
|
| The current per-category snapshot. Always includes |
|
|
|
|
|
|
|
|
|
|
| Mirrors |
|
| The resolved regulation set applicable to this visitor (region-dependent), from the consent engine. |
Methods
Method | Description |
|---|---|
| Opens the phase-1 banner (never the preference center), regardless of how the site is configured to auto-show. |
| Hides the banner without recording any decision. |
| Re-prompts the visitor on the site's configured surface — the banner, or straight to preferences if |
| Opens the preference center (second layer / modal) directly, regardless of |
| Revokes all non-necessary consent and re-blocks scripts that had been unblocked. |
| Programmatically records a specific per-category decision, bypassing the banner UI entirely — e.g. for a custom consent widget you build yourself. |
| Force a reactivation pass over currently-blocked elements against the present consent state. Rarely needed by hand; the engine calls this itself on every decision. |
| Injects a bare |
| Jumps to a named view inside a flow-based (Banner Studio v2) banner. A no-op if the active banner is a v1 banner or hasn't mounted yet. |
| Returns the current view id in a v2 flow banner, or |
| Shorthand for |
There is no renewCookieBotConsent() or similarly Cookiebot-specific alias — the method names above are the Cookiebot-compatible names.
onConsentChange(callback)
const unsubscribe = CookieMunch.onConsentChange((state) => {
console.log('marketing granted:', state.marketing);
});
// later
unsubscribe();The callback receives the full ConsentState (the internal shape, a superset of the public consent snapshot) and fires on the accept and decline engine events only — deliberately not on the internal consentReady event, even though consentReady also carries a valid state. The engine emits consentReady immediately before accept/decline on every explicit action, so including it would double-fire your callback per user action; for a returning visitor with stored consent, accept/ decline are (re-)emitted during engine.init(), so the returning-visitor case still reaches your callback exactly once, without you needing to de-duplicate.
Lifecycle events
Every lifecycle transition is also dispatched as a CustomEvent on window, under both CookieMunch* and Cookiebot* names, with the state in event.detail:
Event | Fires when |
|---|---|
| The embed has finished bootstrapping. |
| The banner is about to be auto-shown for the first time this visit. |
| The banner or preference center becomes visible — including manual re-opens via |
| The visitor accepted (fully or partially). |
| The visitor declined. |
| A valid consent state now exists — fires for both fresh decisions and returning-visitor hydration. |
| Previously-blocked tags have finished being reactivated. |
window.addEventListener('CookieMunchOnAccept', (e) => {
console.log('consent state:', e.detail);
});Equivalently, define a global function named CookieMunchCallback_On<Event> (or the Cookiebot-prefixed variant, e.g. CookiebotCallback_OnAccept) and the embed invokes it directly with the state — no addEventListener required. This is Cookiebot's exact callback convention, so an existing CookiebotCallback_OnAccept function defined on your page keeps firing unmodified after switching the <script> tag.
A misbehaving listener (throwing) is caught internally and logged to the console — it can never break the consent flow for other listeners or for the page.
Declarative triggers (no JS required)
Any element with data-fc-open="banner" or data-fc-open="preferences" opens the corresponding surface on click, with zero wiring:
<a href="#" data-fc-open="preferences">Cookie settings</a>
<a href="#" data-fc-open="banner">Manage cookies</a>data-cc="show-settings" is also recognized, as a Cookiebot-compatible alias for data-fc-open="preferences". Both are handled by a single delegated click listener the embed attaches to document, so they work on elements added to the page after load, without re-registering anything.
Gating third-party code: a complete example
<script id="CookieMunch" src="https://cdn.cookiemunch.net/consent.js"
data-cbid="your-site-id" data-blockingmode="manual"></script>
<script>
function boot() {
if (!window.CookieMunch) return; // embed failed to start (e.g. missing cbid)
var c = CookieMunch.consent;
if (c.statistics) loadAnalytics();
if (c.marketing) loadAdNetwork();
CookieMunch.onConsentChange(function (state) {
if (state.statistics) loadAnalytics();
if (state.marketing) loadAdNetwork();
});
}
window.addEventListener('CookieMunchOnLoad', boot);
</script>With data-blockingmode="manual" your own gating code, rather than the auto-blocker, is responsible for not calling loadAnalytics()/loadAdNetwork() before consent is granted — see script blocking & data-attributes for the markup-based alternative that needs no such gating code at all.
Next: script blocking & data-attributes for prior-blocking markup, or back to embed scripts for install-tag details.