Skip to main content
Question

Determining the Uniqueness of Entitlements on the Server After Restoring a Purchase

  • February 22, 2025
  • 1 reply
  • 15 views

Forum|alt.badge.img

In my mobile application, users can create accounts.
When logging into an account, I call logIn() in the RevenueCat SDK to set a custom app_user_id.
When logging out, I call logOut().

 

Subscriptions are only available to authenticated users.

 

Users can create groups within the app.

When a user purchases a subscription, premium access is granted to all members of their group.

 

To handle this, I have a table in the database that stores data about the active entitlement:

 

PremiumTable:

• id (autoIncrement primary key)

• Purchase date

• Expiration date

• groupId – the ID of the group that received premium access

• ownerUuid – the ID of the user who made the purchase (I’m unsure whether to store app_user_id or original_app_user_id here).

 

The issue I’m facing:

1. A user creates a group.

2. He purchase a premium subscription, and a record is created in PremiumTable.

3. He log out, which resets the RevenueCat app_user_id.

4. He log in with a different account associated with a different group.

5. He press Restore Purchase. At this point, premium access should be granted to their new group and revoked from the old one.

 

However, when Restore Purchase is triggered, the subscription transfers to the new user with completely different IDs:

 

First login:

• app_user_id = abd95cab-0937-40e9-9afc-f989c6ac4d92 (after calling logIn())

• original_app_user_id = $RCAnonymousID:b3b542ff6dd74da29b60aaf708277658

 

After logging into a second account and calling Restore:

• app_user_id = 0ff61b7e-1e8c-4746-90c0-610656bff9db

• original_app_user_id = $RCAnonymousID:c7b8c272747241d8b630eab3a754fb7f

 

Since the subscription is transferred, I am unable to send a request from the client to the server to update/create a new record in PremiumTable because I cannot identify the previous record in the database to revoke premium access from the old group.

 

I know that using webhook transfer events is a possible solution, but I’m wondering if there is a way to handle this without using webhooks?

This post has been closed for comments

1 reply

jeffrey_bunn
RevenueCat Staff
Forum|alt.badge.img+6
  • RevenueCat Staff
  • 240 replies
  • February 26, 2025

Hi ​@dimabiryuk! Ordinarily, I would suggest webhooks, as we include aliases within the webhook body which would contain your non-anonymous app user ID (which you could then use to update your database accordingly).

If it’s not possible to use webhooks, perhaps you could avoid calling logOut, and instead only call login again when the new user authenticates. The reason this could possibly work is logOut creates an anonymous user. If you avoid the creation of anonymous users, you could store the “current” app user ID before your app authenticates a new user and calls login, and use this stored ID to call your backend. This adds a fair amount of complexity, so if webhooks are at all possible I would still recommend them instead.


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings