---
title: "Responding to OneTrust Consent State Changes"
canonical_url: https://ot.webclat.com/guides/respond-to-consent-state-changes
description: "OneTrust's SDKs fire a callback the instant consent changes, so scripts can react live instead of on a timer or the next page load - here's how to wire and verify that listener."
source: Webclat | OneTrust Solutions (OneTrust partner, independent consultancy)
---

# 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

- [How do I fire a GTM trigger the instant a visitor updates their consent choice, without a page reload?](https://ot.webclat.com/qa/gtm-consent-update-trigger)
- [OneTrust JavaScript consent events: what to listen for and why](https://ot.webclat.com/guides/onetrust-javascript-consent-events)
- [Stop guessing which tags fire before consent](https://ot.webclat.com/use-cases/stop-guessing-which-tags-fire)

Contact: ot@webclat.com | (813) 694-4451 | https://ot.webclat.com/#contact