Docs · für Entwickler
Runtime-API
Alles, was das Banner kann, ist skriptbar. Die Runtime stellt ein Global bereit, feuert fünf Events und rendert gar keine UI, wenn Sie lieber Ihre eigene bauen.
Das Global
window.CookieCrumbs.ready.then(() => {
const choice = window.CookieCrumbs.get();
// { necessary: true, analytics: false, … } or null before any decision
});| Member | Was es tut |
|---|---|
ready | Promise, das aufgelöst wird, sobald Konfiguration und Zustand geladen sind. |
get() | Die aktuelle Kategorienzuordnung oder null vor einer Entscheidung. |
set(partial) | Eine Entscheidung programmatisch zusammenführen und aufzeichnen. |
acceptAll() / rejectAll() | Eine vollständige Erteilung oder Ablehnung aufzeichnen. |
withdraw() | Einen Widerruf aufzeichnen (alles aus, als widerrufen typisiert). |
open(layer?) / close() | Das Banner öffnen (Ebene 2 ist das Einstellungsfenster) oder ausblenden. |
consentId() | Die pseudonyme Consent-ID des Besuchers oder null. |
version() / regime() / country() / lang() | Die Live-Versionsnummer, das aufgelöste Regime, das erkannte Land und die aktive Sprache. |
setLang(tag) | Die Banner-Sprache wechseln (muss konfiguriert sein). |
declaration(el?, lang?) | Die Cookie-Erklärung in ein Element rendern (Standard: das erste [data-cc-declaration]). |
declarationUrl(lang?) | Die URL der gehosteten Erklärung. |
myConsent() | Der eigene gespeicherte Datensatz des Besuchers, für eine „Meine Einwilligung“-Seite. |
on(event, cb) / off(event, cb) | Events abonnieren. |
sdk | Der Versionsstring der Runtime. |
Events
Fünf Events: ready, show (eine Ebene geöffnet), decision, update (eine geänderte Entscheidung) und withdraw. Events der Entscheidungsfamilie tragen { categories, type, consentId, regime }.
Das Wiederöffnen-Element
Jedes Element mit data-cc-open öffnet das Banner wieder: <a href="#" data-cc-open>Cookie-Einstellungen</a>. Besucher müssen immer einen Weg zurück haben; wenn Sie den schwebenden Button deaktivieren, ist dieser Link Pflicht.
Headless-Modus
Mit dem Headless-Layout wird gar kein Banner gerendert. Sie bauen die Oberfläche und steuern sie vollständig über diese API; Blockierung, Einwilligungsprotokoll, Regime und Consent Mode arbeiten darunter weiter.
Wie Blockieren und Freigeben tatsächlich funktionieren
Der Interceptor installiert sich synchron, vor dem Laden der Konfiguration. Getaggte Skripte (type="text/plain" mit data-cc-category) und ungetaggte Skripte oder iFrames, deren Host zur veröffentlichten Block-Map passt, bleiben neutralisiert im DOM und werden in Dokumentreihenfolge neu erzeugt, sobald ihre Kategorie erlaubt wird. Einmal freigegebene Knoten werden nie wieder neutralisiert.
Embed-Code bei Einwilligung
Ein im Dashboard erfasster Tracker kann eigenen Embed-Code tragen. Beim Veröffentlichen wird er in die Konfiguration kompiliert, und die Runtime führt jeden Eintrag genau einmal aus, wenn seine Kategorie erlaubt wird, zum Entscheidungszeitpunkt oder bei einem späteren Besuch mit gespeicherter Einwilligung. Bereits gelaufener Code kann durch einen Widerruf nicht rückgängig gemacht werden; er läuft beim nächsten Seitenaufruf einfach nicht erneut.
Zustand, ehrlich
Die Entscheidung lebt in einem First-Party-Cookie, cc_consent (SameSite=Lax, Secure auf https), und überlebt so Reloads. Consent-Events reihen sich in localStorage["cc:q"] ein und werden an den Consent-Endpunkt gesendet, mit sendBeacon als Fallback beim Schließen der Seite; die Warteschlange wird nur bei Erfolg geleert, sodass eine fehlgeschlagene Zustellung beim nächsten Laden erneut versucht wird. Neben einem Einwilligungsdatensatz werden weder IP-Adresse noch User-Agent noch Seiten-URL gespeichert.