SDK reference

The browser-side surface is deliberately small. There is one public method, one DOM event, one cookie, and the Google Consent Mode integration.

window.ConsentinelCloud

Available once the SDK has initialized.

showPreferences()

Opens the preferences modal. This is the whole public API — it exists so you can wire your own "Cookie settings" link, which most privacy policies and footers need.

<a href="#" onclick="window.ConsentinelCloud.showPreferences(); return false;">
  Cookie settings
</a>

Guard the call if your link can render before the bundle has run:

if (window.ConsentinelCloud) window.ConsentinelCloud.showPreferences();

There are deliberately no state getters and no event bus here. To react to consent, use the DOM event below.

Use ConsentinelCloud, not Consentinel. A window.Consentinel object also exists — it is the blocker's internal state and is not a supported API. Which code owns that name depends on the deployment: on a WordPress site running the Consentinel plugin's own local blocker, the plugin owns it. The preferences API lives on a distinct global precisely so the two surfaces can never shadow each other. Build against ConsentinelCloud and the consentinel:applied event only.

The consentinel:applied event

Dispatched on document whenever consent is applied — on page load with stored consent, and again whenever the visitor changes their choices.

document.addEventListener('consentinel:applied', (e) => {
  // e.detail is the consent state, keyed by category
  if (e.detail.analytics) {
    // start something that needs analytics consent
  }
});

e.detail is an object mapping each configured category to 1 (granted) or 0 (denied) — for example { necessary: 1, analytics: 1, marketing: 0 }. The necessary category is always 1.

Categories are configurable per site, so read the keys rather than assuming a fixed set.

Listen before you need it. Register the listener above your other scripts; the event fires early for a returning visitor with stored consent.

The consent cookie

Name and lifetime are configurable per site in the dashboard.

The cookie records the visitor's choice locally so the banner does not reappear. The authoritative record is the consent event stored server-side, which is tied to the exact configuration version that was on screen when the visitor chose — that link between a choice and the banner that produced it is the point of keeping the log.

To check state in the console, see Verify your install.

Blocked-script markers

When the blocker neutralizes a tracker, it leaves the evidence in the DOM rather than removing the element:

<script type="javascript/blocked" data-consentinel-blocked="pagesense"></script>

• type="javascript/blocked" — the browser will not execute it
• src — stripped
• data-consentinel-blocked — the catalog id of the tracker it matched

To list everything blocked on the current page:

[...document.querySelectorAll('[data-consentinel-blocked]')]
  .map(s => s.dataset.consentinelBlocked)

When consent is granted, the blocker restores these tags and they execute normally.

Google Consent Mode

Consentinel emits Google Consent Mode v2 signals when enabled in Customize → Behavior. Keep your tag manager — consent-aware tags inside it respond to these signals correctly.

We use Google's basic consent mode. Google's tags stay fully blocked until the visitor consents. Google's advanced mode requires its tags to load before consent and send cookieless pings, which is precisely the pre-consent transmission our product exists to prevent, so we do not offer it.

The defaults pushed before any consent decision:

gtag('consent', 'default', {
  ad_storage: 'denied',
  analytics_storage: 'denied',
  ad_user_data: 'denied',
  ad_personalization: 'denied',
  functionality_storage: 'denied',
  personalization_storage: 'denied',
  security_storage: 'granted',
  wait_for_update: 500,
});

ads_data_redaction starts on — click identifiers are redacted before any consent decision — and then tracks the marketing consent state, so granting consent actually clears it. url_passthrough, which preserves ad attribution across a decline, is a per-site option in Customize → Behavior and is only set when you enable it.

dataLayer events

Two events are pushed for use as GTM triggers:

consentinel_update carries the new state on its consent property.

Stored consent is pushed synchronously during boot, not on DOMContentLoaded. That timing is deliberate: a Google tag in <head> reads the consent state immediately, and pushing later meant returning visitors who had already consented were silently unmeasured on every page load.

Global Privacy Control

A visitor sending the GPC browser signal is treated as having opted out. Non-essential categories are set to denied, the choice is recorded server-side with GPC named as the method, and the banner is suppressed rather than asking someone to repeat a decision their browser already communicated.

This runs ahead of any opt-out seeding, so a GPC visitor has nothing non-essential running regardless of the site's compliance mode.

What is not in the browser API

Consent records, scan results, configuration and published versions are not readable from the page. There is no client-side write path to the consent log — events are written by the consent API from the SDK's own request and by nothing else. This is a deliberate boundary: the value of the record is that the site being audited did not author it.

Programmatic access to that data is a dashboard and API concern, not an SDK one.