Transfer Purchases vs Block Restores

  • 27 April 2022
  • 0 replies

Badge +4

Hi all,

EDIT - found this post very useful - it doesn’t entirely answer the question I have but certainly sheds a lot more light on it.

Apologies for the second post in a short time. It’s on a related topic, but not identical.

Can someone explain why the following is occurring please?

  • RevenueCat initialised and anonymous App User ID is created
  • We create our own App User ID and call the logIn() function, passing that ID in
  • We make a purchase
  • When our Webhook runs, we receive the new App User ID (created by us) in the app_user_id field, but we receive the old, anonymous App User Id (created by RC) in the original_app_user_id field.

In theory this shouldn’t be a problem and we should be able to ignore the original_app_user_id field as irrelevant information, but we need to use Block Restores to ensure that purchases are assigned to one Apple ID and one only. We don’t want to move them between different Apple accounts.

But when I read the docs, it says this:


Block Restores

Use with caution 🚧

Returns an error if the App User ID attempting to restore purchases is different from the original App User ID that made the purchase. This requires customers to sign in with their original App User ID, and is only allowed for apps that require every customer to create an account before purchasing.


The underlined part is where I’m concerned. I assume by “original App User ID” this refers to the original, anonymous ID that we are seeing in the original_app_user_id field in the webhook?

Does that mean that we can’t make any future changes using the ID we created, as RevenueCat has to have them assigned to the original, anonymous ID?



0 replies

Be the first to reply!