# Consent Management in Mobile SDKs

This guide covers the consent management feature available in the RudderStack Android (Kotlin) and iOS (Swift) SDKs.

Consent management lets your app tell RudderStack what the user agreed to. Once you supply the user’s consent choices, the SDK does two things automatically for the rest of the session:

Stamps every event with the user’s consent state, under context.consentManagement. Your events to the cloud mode destinations are then filtered server-side using that stamp.
Blocks device mode destinations the user has not allowed. A denied destination is never initialized, and it receives no events.

You keep ownership of the consent UI. The SDK never shows a banner, never stores a choice, and never asks the user anything — it only acts on the consent values you hand it.

This feature supports the Custom consent provider only. Named consent managers such as OneTrust, Ketch, and iubenda are not supported by the mobile SDKs yet. If you use one of those platforms, you can still use this feature — read the user’s choices from your CMP’s own SDK and pass them to RudderStack as custom consent category IDs.

While consent management is active, every event carries the user’s consent state in its context:

json

{
  "context": {
    "consentManagement": {
      "provider": "custom",
      "allowedConsentIds": ["marketing", "analytics"],
      "deniedConsentIds": ["advertising"]
    }
  }
}

Each event keeps the consent values that were in force when the event was created. If the user changes their consent while an event is still being processed, that event still reports what the user had agreed to at the time, so your record of consent stays accurate.

When consent management is not active, the consentManagement block is absent entirely.

context.consentManagement is owned by the SDK while consent management is enabled. If your own code or a custom plugin writes to that key, the SDK overwrites it and logs a warning.

Persistence and identity

Consent is not persisted. The SDK holds the consent state in memory only, and it is gone when the app is killed. Your app or your CMP owns the durable copy — supply it again on every launch.
reset() does not clear consent. Resetting the user identity leaves the consent state untouched, because consent is a device-level choice rather than a property of the signed-in user.
Kotlin SDK: Android only. Consent management is not available in the server-side (JVM) artifact.

FAQ

No. setConsent only sets the state — there is no getter. Keep your own copy of the user’s choices in your app or your CMP, and treat that as the source of truth.

Set the log level to verbose or debug. See Logging APIs in Mobile SDKs. The SDK logs each event it drops and which destination it dropped it for, and warns whenever a call you made had no effect.

Consent on the event

Persistence and identity

FAQ

Can I read the current consent state from the SDK?

How do I see what consent management is doing?

See more