How to check the entitlement of an Anonymous user via restful API?

  • 10 April 2023
  • 3 replies

Badge +2

For example this is how I would fetch the info about a user.


First I need to set the unique user id during the configuration:



Then after a purchase I could simply obtain it:

http get$USER_ID Authorization:"Bearer XXXX" Content-Type:"application/json" X-Platform:android accept:"application/json"


The problem with userID is that they will get lost, if the user deletes the app and reinstalls it, and will no longer have access to the existing purchases.  The only way would be creating an email signup in the flow, which I was hoping to avoid.


The other way is to use anonymous users:


Now ReveneCat can create aliases and merge the ids upon reinstallation as long as it’s the same user in Google PlayStore that made the purchases.


This solves the problem, but now I have no way to double check the entitlement from the server side through RevenueCat’s RestAPI. Because the following doesn’t seem to work, unless I’m overlooking something


ANONOMOUS_USER_ID = Purchases.sharedInstance.appUserID

http get Authorization:"Bearer XXXX" Content-Type:"application/json" X-Platform:android accept:"application/json"

Many Thanks

3 replies

Userlevel 4
Badge +8

Hi, your API request is not working because of the way you have inputted the user id. You’ll instead want it be like this %24RCAnonymousID%3A945d6ad20af8402e832b897337dc4dbc. You need to include the $ at the beginning of the user id, but you also must handle special characters. You can actually input your information into our REST API page and then can copy and paste the query into Postman/command line/etc. to run it. Please try that and let me know if it works!

Badge +2

Hi Haley,


Thank you so much for the answer. Yes, that worked. I should have encoded the URL in the first place.

Haley, we are still having a hard time getting our head around restoring purchases.

The documentation says the following:

The default behavior is to transfer purchases between identified App User IDs if needed. This ensures that the customer restoring gets access to any purchased content, but only one customer at a time can have access. For example, if UserA buys a subscription, then UserB logs into your app on the same device and restores transactions, UserB would now have access to the subscription and it would be revoked from UserA. 

If an identified App User ID restores and the owner of the receipt is anonymous, the anonymous identifiers will be merged (aliased) into the same customer profile in RevenueCat and treated as the same customer going forward. If an anonymous ID restores and the owner of the receipt is an identified App User ID, we will resort to the specified restore behavior and transfer the receipt to the anonymous user. And finally, if an anonymous ID restores and the owner of the receipt is also anonymous, the anonymous identifiers will be merged (aliased).


In other words, it doesn’t matter if purchases are made anonymously vs loggedIn with an identified App User Id. In all four scenarios the user that restores the purchases will snap the previously purchased subscription on the given PlayStore account.

So why even bother with making a purchase with an identifiable App User Id?


Many Thanks,



Userlevel 4
Badge +8

Hi, sorry for the late reply! Using an identifiable App User Id is all up to preference, for example if it is easier for you to track this on your end. You can easily do user authentication etc. with our default $RCAnonymous ids