setPushIdentifier() and denylisted field

[Julio_Baixauli]

Hi Masters,

We've configured push notifications in an Android app. We can send notifications using both the Assurance push test and the AJO Campaign. My question is related to the denylisted field in the (xdm:) pushNotificationDetails.

As per [1], "The token can be denylisted for various reasons, like the user has uninstalled the app or the user has disabled push messaging for the app."

However, we have conducted multiple tests by disabling app notifications from the Android settings, but the denylisted field in the AEP profile (pushNotificationDetails.0.denylisted) for the user is always set to false. My question is: when is the denylisted field updated? Does the app need to call any API method to update this field?

Furthermore, in [2], it is stated that denylisted "Indicates whether the push token is blocked by the push provider," which seems like a different definition compared to [1].

So, is it best practice to use the denylisted field to check if a profile (user) has allowed push notifications in their app? This question also relates to user consent/preferences, which I find somewhat confusing.

Any tips would be appreciated! Thanks!

[1] https://experienceleague.adobe.com/en/docs/experience-platform/assurance/view/push-debug-view#profil...
[2] https://github.com/adobe/xdm/blob/master/docs/reference/fieldgroups/profile/profile-push-notificatio...

Kind regards,

[Silvio6]

Hi! I'm facing same issue...do you have any answers to your questions?

[Julio_Baixauli]

Not really.
As far as I understand, the denyListed field is automatically managed by the SDK. I’ve seen some of my profiles with denyListed = true, and I assume it's the messaging service (Android Firebase or Apple APNs) that flags the push tokens as denyListed to the SDK, which then updates the profile accordingly — but I might be wrong.

If you want to manage push consents, you should probably use the consents.marketing.push.val field instead.

[Julio_Baixauli]

This is from Adobe Support:

1.) What triggers the denylisted flag?

The denylisted flag is set to true only after AJO attempts to send a push notification and the push provider (e.g., FCM for Android) responds with a permanent failure — such as:

- NotRegistered

- InvalidRegistration

- Other “no such token” or “invalid token”

Common causes include:

- The user uninstalls the app.

- The OS or vendor revokes the token.

Simply disabling push notifications in Android settings does not cause denylisted to flip to true. This is because FCM continues to accept the token and deliver the message (the OS just suppresses the display).

2.) When are denylisted and token updated?

The feedback from the push provider is received synchronously at the time of delivery attempt. Writing that information back to the profile (updating denylisted and clearing the token) is handled as an asynchronous update to UPS. In most cases, the update is visible within a few seconds, but it can take 5-10 minutes or even a bit longer in busy tenants or under load.

3.) Why do we see denylisted = true and token = ''?

When a token is declared invalid:

- AJO sets denylisted = true.

- AJO clears the token (sets token = ' ' ) to ensure it is not selected for future deliveries.

4.) Does the app need to call any API to update these fields?

No- the app doesn’t need to and cannot update denylisted directly. The SDK registers tokens using setPushIdentifier() (or removes them when you pass null). The denylisted status is determined entirely by AJO after it receives feedback from the push provider.

5.) Why didn’t uninstall appear to change the field in our tests?

FCM may continue to accept a token for a short time after the app is uninstalled. If you reinstall the app quickly, FCM might even return the same token and continue reporting successful delivery.

To observe the denylisted update, try:

- Sending another push after a short wait.

- Clearing app data to force a new token.

- Waiting longer before sending a test push post-uninstall.