Responding to consent state changes without polling
What it is
Rather than polling for the current consent state on an interval, OneTrust's SDKs expose a callback that fires the moment a visitor's consent actually changes - a new choice, a revocation, or a change synced from another surface - so an application can react immediately by loading a script, tearing one down, or refreshing UI, instead of waiting for the next page load or checking on a timer.
When you need it
A script needs to start or stop the instant a category is granted or revoked, not on the next page load - the tag-management equivalent of this pattern is covered on this site's own gtm-consent-update-trigger page.
A single-page application hosts its own consent-preferences UI and needs the rest of the app to react live when a visitor changes a choice mid-session.
You're debugging a script that only seems to respect consent after a full reload and suspect it's reading state once at load time instead of listening for changes.
How to implement it
- 1
Register the change listener once, during initialization
Attach it during your application's startup sequence rather than repeatedly attaching and detaching it across renders, which risks either missed events or duplicate handling.
- 2
Read exactly which category or purpose changed from the event payload
Use the specific change the event reports rather than re-reading the entire consent state and diffing it yourself - the event already tells you what moved.
- 3
Route each category's change to the specific dependent logic
Use the same category-to-consumer mapping you'd use for gating any script - this site's own tag-governance use case covers building that map for a Google Tag Manager container specifically.
- 4
Guard against the listener firing before dependent logic has initialized
Consent state can resolve before the rest of the page has fully mounted in some load sequences - confirm your handler doesn't silently no-op because the thing it's supposed to trigger isn't ready yet.
- 5
Confirm the callback fires once per actual change, not once per re-render
In frameworks that re-run effects on unrelated state changes, verify the listener isn't being re-registered (and its logic re-run) more often than the underlying consent state is actually changing.
How to verify it worked
Open the consent-preferences UI, change exactly one category, and confirm only the logic tied to that category runs - add a temporary log statement if needed to isolate it.
Revoke a previously granted category and confirm the corresponding teardown logic actually executes, not just the grant-path logic.
Test the listener's registration timing against your app's own mount sequence to confirm it isn't missing an unusually early consent resolution.
Related
Want this scoped against your specific OneTrust tenant?
We scope every engagement in discovery, before implementation - no assumptions about your stack.