In reading over the documentation, I see that the appAccountToken in the StoreKit transaction is only set if the app user ID is a UUID (https://www.revenuecat.com/docs/platform-resources/server-notifications/apple-server-notifications#user-identity).
We use firebase for auth and their user IDs are not UUIDs. We can generate a UUID from the Firebase ID, but we’d need to to create a UUID → Firebase UID lookup. We can easily do this if necessary, but I’m not clear on the benefits. "
What do we lose out on if appAccountToken is not set because we aren’t using UUIDs?
Solved
What functionality do we lose if we don't use a UUID for app user ID?
Best answer by guilherme
Hey
Since Firebase UIDs aren’t UUIDs, this field will be empty unless you generate and use a UUID as the App User ID in RevenueCat (and then through a mapping in your system, as you mentioned.
This is important for Apple StoreKit server-to-server (S2S) notifications, which are used to track subscription events (like renewals, cancellations, billing issues) without relying on the app being open. RevenueCat listens to these notifications to update user status and trigger webhooks or integrations.
If appAccountToken is set, RevenueCat can link the incoming transaction directly to your user. If it’s not set, RevenueCat creates a new anonymous user and attaches the purchase there.
As to what can happen without it:
-
User identity fragmentation: purchases may get linked to a new anonymous user instead of your actual App User ID.
-
Broken restore flows: when a user reinstalls or switches devices, their subscription may not map correctly unless the SDK posts the receipt again.
-
Missing or misaligned attributes: customer attributes you sync (like email or device) may end up on the wrong user ID, breaking integrations.
-
Transfer behavior complexity: if you're relying on "keep with original App User ID" or similar logic, the absence of
appAccountTokencan create unexpected behavior.
You’ll still get basic purchase tracking and entitlement unlocks, but data consistency and supportability will suffer.
If you plan to rely on StoreKit server notifications or want clean user identity across devices and platforms, we strongly recommend generating a UUID for each user and using that as the App User ID in RevenueCat.
More context on the transfer behavior:
Best,
+3Hey
Since Firebase UIDs aren’t UUIDs, this field will be empty unless you generate and use a UUID as the App User ID in RevenueCat (and then through a mapping in your system, as you mentioned.
This is important for Apple StoreKit server-to-server (S2S) notifications, which are used to track subscription events (like renewals, cancellations, billing issues) without relying on the app being open. RevenueCat listens to these notifications to update user status and trigger webhooks or integrations.
If appAccountToken is set, RevenueCat can link the incoming transaction directly to your user. If it’s not set, RevenueCat creates a new anonymous user and attaches the purchase there.
As to what can happen without it:
-
User identity fragmentation: purchases may get linked to a new anonymous user instead of your actual App User ID.
-
Broken restore flows: when a user reinstalls or switches devices, their subscription may not map correctly unless the SDK posts the receipt again.
-
Missing or misaligned attributes: customer attributes you sync (like email or device) may end up on the wrong user ID, breaking integrations.
-
Transfer behavior complexity: if you're relying on "keep with original App User ID" or similar logic, the absence of
appAccountTokencan create unexpected behavior.
You’ll still get basic purchase tracking and entitlement unlocks, but data consistency and supportability will suffer.
If you plan to rely on StoreKit server notifications or want clean user identity across devices and platforms, we strongly recommend generating a UUID for each user and using that as the App User ID in RevenueCat.
More context on the transfer behavior:
Best,
Thank you
One suggestion that would be useful for future integrators - it’d be nice if you could set a customer attribute $appleUuid similar to $mixpanelDistinctId and other integration identifiers so that we could use our actual user IDs and still get this functionality. Even better would be if RevenueCat did this under the hood. For example, if the user ID is not a UUID, generate a deterministic UUID using uuidv5 and associate this with the RevenueCat customer as an additional alias or attribute.
Reply
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.