SDK reference

The browser-side surface is deliberately small. There is one public method, a set of markup hooks for your own controls, 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.

Consent controls in your own markup

Beyond showPreferences(), the SDK listens for clicks on any element carrying a data-cg-action attribute, anywhere in your page. Put the attribute on your own button or link and the SDK does the rest — you write the markup and the styling, it handles the behavior.

The listener is delegated on document, so controls added after page load work without re-registering anything.

dns — "Do Not Sell or Share My Personal Information"

California's CCPA/CPRA expects a clear and conspicuous control with this title on sites that sell or share personal information. The SDK does not create one for you — you place it, because only you know where it belongs in your layout.

<button type="button" data-cg-action="dns">
  Do Not Sell or Share My Personal Information
</button>

A single click does all of the following, with no modal and no second step:

• Turns marketing, analytics and social off
• Writes the consent cookie and reconfigures the blocker
• Records the choice against your site, with method do-not-sell
• Expires cookies belonging to the categories just denied
• Sets data-cg-state="opted-out" on the element and updates its label
• Reloads the page, so trackers already running stop

Because the element gets data-cg-state="opted-out", you can style the post-click state yourself:

[data-cg-action="dns"][data-cg-state="opted-out"] { opacity: .7; }

On WordPress. The Consentinel plugin renders this control for you via the [consentinel_do_not_sell] shortcode, a Gutenberg block, or an Elementor widget. Those emit the same markup, so they work identically whether or not the site is connected to Consentinel Cloud — the plugin renders, the bundle handles the click.

Not legal advice. Whether your site needs this control, what it must be called, and where it must appear are questions for your own counsel. The SDK gives you a control that works; placement and prominence are yours.

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 whose browser exposes navigator.globalPrivacyControl 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 such a visitor has nothing non-essential running regardless of the site's compliance mode.

The JavaScript property is what drives that, not the Sec-GPC request header. A page cannot read its own request headers, so a browser that sends the header without exposing the property gets the ordinary banner — the signal is still recorded, but nothing was suppressed on its account. The two are recorded as separate fields (gpc for the header, gpc_signal for the property) and never merged, precisely so this gap is visible in your evidence rather than hidden behind a single flag. In our own fleet the two disagree on roughly a quarter of GPC events, always in the direction of the property being present without the header.

A GPC visitor can still change their mind, and that is recorded as such. If they open the preferences panel and grant a category, the grant takes effect — it is their explicit choice — and the event is stored with the method gpc_override so the conflict is auditable. The server records what the browser actually did; it does not rewrite the categories to match the signal, because that would produce evidence contradicting the page.

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.