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.
⚙️ Reopening the settings from your own link
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.