Events

You do not need this page to make consent work. Consentio already tells Google’s tags what they may do, on its own.

This is for the other case: you have code of your own that should only run if the visitor allows it. For a script tag — an embedded map, a chat widget, a heatmap tool — you do not need code at all: mark the tag with the category it needs and Consentio releases it when that category is granted. The events are for what a tag cannot say: a call that takes the visitor’s answer, or a script that has to load some other way.

📣 The two events

Both are fired on document, and both carry the visitor’s answers.

Event When it fires
consentio:consent-update Every time someone accepts all, rejects all, or saves their choices
consentio:initialized Once, when the banner is put on the page — carrying the stored answer, or each category’s default state when there is none

📄 Loading something only when it is allowed

You need to handle two people: the one answering right now, and the one who answered on a previous visit and will never see the banner again.

function onAllowed(consents) {
  if (consents.statistics_performance !== 'granted') return;
  // load your script here
}

// Someone answering now.
document.addEventListener('consentio:consent-update', (e) => onAllowed(e.detail));

// Someone who answered on a previous visit.
document.addEventListener('consentio:initialized', (e) => onAllowed(e.detail));

detail is the answers, one per category:

{
  strictly_necessary: 'granted',
  preferences_functionality: 'denied',
  statistics_performance: 'granted',
  marketing_advertising: 'denied'
}

For a visitor with no stored answer, detail is what the switches start at. With the defaults every category but strictly_necessary starts denied, so the listener above loads nothing for them. A category you start at granted in the settings file is the exception: it reads as granted before anyone has answered.

Register the consentio:initialized listener early — in the <head>, or at the top of your own script. It fires while the banner is being built, and a listener added after that will never see it. The consentio:consent-update one can be added whenever you like.

🚫 Make sure it can only run once

consentio:consent-update fires every time someone saves, so a visitor who opens the settings twice will trigger your code twice. Guard it:

let loaded = false;
function onAllowed(consents) {
  if (loaded || consents.statistics_performance !== 'granted') return;
  loaded = true;
  // load your script here
}

There are no other events and no callback options in the settings. These two are all of it.

A visitor who has answered gets a round button in the bottom right corner, and that is the only way back in until you add one. window.ConsentioInstance.openSettings() opens the panel from anywhere on the page — a footer link, a line in your cookie policy.

Guard on window.ConsentioInstance. The banner is fetched in the background, so a link clicked in the first moment of a page load can run before it exists. Without the guard that click is a console error and no panel.

<a href="#" id="cookie-settings">Cookie settings</a>

<script>
  document.getElementById('cookie-settings').addEventListener('click', (e) => {
    e.preventDefault();
    if (window.ConsentioInstance) window.ConsentioInstance.openSettings();
  });
</script>

Calling it while the panel is already open does nothing, so a second click cannot disturb where the visitor has tabbed to. Calling it before the banner is on the page is ignored too, and with debug on the console says openSettings ignored - the banner is not on the page yet.

If you turn the round button off, this link is the only way back in. Set hideFloatingButton — on either route — only once your own link is on every page. Consentio warns on the console when the option is set, because it cannot see whether you added one.