Skip to main content
Solved

Granting

  • May 7, 2026
  • 8 replies
  • 68 views
J
Forum|alt.badge.img

Hi all,

I've launched a privacy-first companion app — no sign-up, no login, no email collection. All data stays on-device by clinical design.

Verified healthcare professionals apply via my website for free access. I want to grant them a 1-year promotional premium entitlement via the dashboard. The catch: I can't search for their customer record because email isn't indexed (and isn't passed via the SDK).

What's the recommended pattern?

Custom App User ID via logIn() with an opaque token I email them?

Or a different approach for apps without sign-up?

Anyone built something similar - all advice is very welcome!

Thanks!

Best answer by Tarek

Hey Julia,

 

Tarek, from the support team here.

 

I'm happy to walk you through the steps to achieve this while keeping your privacy-first design.

Every one of your customer using RevenueCat is uniquely identified. If you provide an App User ID when calling .configure or .login, then this user ID is used, otherwise, an anonymous user ID is generated on your behalf (prefixed with $RCAnonymousID).

 

You can retrieve this App User ID client side by reading Purchases.shared.appUserID and displaying it somewhere in your app so that your users can easily share it with you. (You can even make for instance a templated email that will include it automatically in the body).

 

Also, the RevenueCat Customer Center displays it as well, so that would be a one-liner in this case.

 

Your custom user ID, or the anonymous ID is enough to access your customer's profile and grant a promotional entitlement there.

 

Let me know if there's anything else I can help you with!

 

Best regards,

      8 replies

      Tarek
      RevenueCat Staff
      Forum|alt.badge.img+5
      • Tarek
      • RevenueCat Staff
      • Answer
      • May 11, 2026

      Hey Julia,

       

      Tarek, from the support team here.

       

      I'm happy to walk you through the steps to achieve this while keeping your privacy-first design.

      Every one of your customer using RevenueCat is uniquely identified. If you provide an App User ID when calling .configure or .login, then this user ID is used, otherwise, an anonymous user ID is generated on your behalf (prefixed with $RCAnonymousID).

       

      You can retrieve this App User ID client side by reading Purchases.shared.appUserID and displaying it somewhere in your app so that your users can easily share it with you. (You can even make for instance a templated email that will include it automatically in the body).

       

      Also, the RevenueCat Customer Center displays it as well, so that would be a one-liner in this case.

       

      Your custom user ID, or the anonymous ID is enough to access your customer's profile and grant a promotional entitlement there.

       

      Let me know if there's anything else I can help you with!

       

      Best regards,

      J
      Forum|alt.badge.img
      • julia-reeve
      • Author
      • New Member
      • May 11, 2026

      Thank you so much! 
      I also got a reply from the revenue cat team.
      I created an area insode my app now where users can see and copy their user ID to send to me so I can identify them and grant the entitlement.
      Thanky ou so much - this is exactly the information I needed and because you verify this - I am sure it will work. I haven`t tried to identify anyone yet but the User ID information inside the app is in my next build!

       

       

      Tarek
      RevenueCat Staff
      Forum|alt.badge.img+5
      • Tarek
      • RevenueCat Staff
      • May 11, 2026

      Glad to hear that ​@julia-reeve!

      I can confirm this will work as expected.

      Let us know if there's anything else we can do for you!

      Best regards,

      M

      Hey ​@Tarek,

      I’m doing something similar in my app, but I’m struggling to make the granted entitlements work cross-device.

      I’ve granted myself an entitlement using the anonymous ID from my iPhone. But when I open my iPad, it has a different anonymous ID. Clicking “Restore purchases” in the paywall didn’t appear to do anything (I was hoping it would merge id’s—not sure how though, maybe using the apple id on the device?). 

      Any advice for this? I’m replying here as I’m expecting Julia to run into the same issue. 🫣

      TIA

        J
        Forum|alt.badge.img
        • julia-reeve
        • Author
        • New Member
        • May 13, 2026

        Thanks for flagging this — yes, this is exactly the architecture limitation I was fearing. For my professional clinician access, I'll be managing this with manual re-grants for now (clinicians email me when they switch devices). Longer-term, I'm planning to move to stable IDs via secure storage so granted entitlements survive reinstalls. Has anyone here implemented the secure-storage approach with React Native + Expo? Would love to hear how it went.

          Tarek
          RevenueCat Staff
          Forum|alt.badge.img+5
          • Tarek
          • RevenueCat Staff
          • May 13, 2026

          Hey ​@martingarnett01 and ​@julia-reeve ,

           

          Yes, this is a limitation that comes from the anonymous / privacy-first architecture.

           

          If you only rely on anonymous identifiers, then there's no way for RevenueCat (or you for that matter) to know if two given users on two different devices are actually the same user.

           

          The only way to reliably link them is to set a unique and stable App User ID for each user.

           

          Also, you don't necessarily need to manual grant entitlement. When restoring purchases on a second device, purchases can be automatically transferred, according to the Restore Behavior you set. But this can quickly turn into a headache for both your users and you if they need restoring purchases each time they switch devices.

           

          Finally, when it comes to secure storage with React Native + Expo, Supabase is quite popular and relatively easy to get started with. There is also Firebase of course. I'm just mentioning what are the go-to standards in the industry, up to you to see if they really fit in your design!

           

          Best,

          M

          Also, you don't necessarily need to manual grant entitlement. When restoring purchases on a second device, purchases can be automatically transferred, according to the Restore Behavior you set. But this can quickly turn into a headache for both your users and you if they need restoring purchases each time they switch devices.

           

          Thanks for the reply! Regarding what you wrote there, this doesn’t match my tests. After granting myself a lifetime entitlement to my Anonymous ID from my iPhone, I was hoping “Restore purchases” on my iPad would grant me the entitlement there (and alias my anonymous ID’s). Both my iPhone and iPad are logged into the same Apple account. Sadly this didn’t happen.

          I suspect it would be fine if the user had actually purchased the subscription, because I’m assuming that would transfer the purchase. As you say though, I can see this getting annoying for users to keep doing. If it becomes a common complaint, I’ll probably just bite the bullet and set up an authentication system.

          It would be nice to be able to manually alias customers for these situations. Or even alias them based on their app store/play store accounts that their device is logged into.

          Tarek
          RevenueCat Staff
          Forum|alt.badge.img+5
          • Tarek
          • RevenueCat Staff
          • May 13, 2026

          Oh yeah, I was indeed talking about the case where a user made an actual purchase. In the case, if they attempt restoring while being signed into the same Apple account, then the transfer would happen.

           

          Customers are not aliased in this case by design, sometimes, different users share the same Apple account on various devices. Automatically merging would mean that profiles that need to stay separated would be incorrectly merged together.

           

          However we do merge/alias on same device when a user goes from an anonymous user ID to a custom one, since in this case it's obvious, and the developer calling login() sends us the signal that this is the same person.

           

          Best,

            Terms & ConditionsAccessibility statement