RevenueCat provides a source of truth for a subscriber's status across different platforms. To do this, each subscriber has an App User ID that uniquely identifies them within your application.

If you don't provide an App User ID when instantiating the Purchases SDK, RevenueCat will create a new random App User ID for you and cache it on the device.

In the event that the user deletes and reinstalls the app, this random App User ID will be unrecoverable and a new random App User ID will be generated. Restoring in-app purchases will recover any subscriptions and alias the new and old random App User IDs together.

Setting your own App User ID will allow you to reference users in the RevenueCat dashboard, via the API, as well as in the webhooks and other integrations.

Using an externally managed App User ID also provides a mechanism by which to restore purchases in a few scenarios:

• When a user deletes and reinstalls your app - using the same App User ID will ensure they still haves access to subscriptions previously started without requiring a restore.
• When the user logs in on multiple devices - you can honor a subscription that was purchased on one device across any other platform.

Set App User ID on instantiation

If you have your own App User IDs, you can pass those on instantiation to Purchases.

Purchases.configure(withAPIKey: "my_api_key", appUserID: "my_app_user_id")

[RCPurchases configureWithAPIKey:@"my_api_key" appUserID:@"my_app_user_id"];

Purchases.configure(this, "my_api_key", "my_app_user_id")

Purchases.configure(this, "my_api_key", "my_app_user_id");

If you don't have an App User ID on instantiation, you can set it later. The most common cases are after registration, when a user switches from being an anonymous user (with a random App User ID) to an authenticated user with some ID, and before a returning user (with a random App User ID) is logged in.

There are two ways to convert an anonymous user to an identifiable user:

• .identify() - set the App User ID to a new user
• createAlias() - merge a new App User ID with the current subscriber

Identify Purchases new a new user

Using .identify() will clear any caches and re-fetch info for the provided App User ID.

The .identify() method should be used to switch the App User ID to a provided App User ID.

Purchases.shared.identify("my_app_user_id") { (purchaserInfo, error) in
    
    // purchaserInfo updated for my_app_user_id
}

[[RCPurchases sharedPurchases] identify:@"my_app_user_id" completionBlock:^(RCPurchaserInfo *purchaserInfo, NSError *error) {
    
    // New user set with purchaserInfo from my_app_user_id
}];

Purchases.sharedInstance.identifyWith("my_app_user_id", ::showError) { purchaserInfo ->
  // New user set with purchaserInfo from my_app_user_id
}

Purchases.getSharedInstance().identify("my_app_user_id", new ReceivePurchaserInfoListener() {
	@Override
	public void onReceived(@android.support.annotation.Nullable PurchaserInfo purchaserInfo, @android.support.annotation.Nullable PurchasesError error) {
		// New user set with purchaserInfo from my_app_user_id
	}
});

Creating Aliases

Aliases are a way for RevenueCat to attach multiple App User IDs to a single subscriber. This allows you to start identifying a user by a provided App User ID without changing the original random App User Id that was assigned by RevenueCat.

There are two ways that aliases are created:

• Calling createAlias manually
• Restoring purchases

Manually Creating Aliases

Using .createAlias() will attach the current App User ID and the provided App User ID to the same subscriber record. This is most often used when an app is configured without a known App User ID and you need to set the App User ID later.

The .createAlias() method should be used to merge the current App User ID with a provided App User ID.

Purchases.shared.createAlias("my_app_user_id") { (purchaserInfo, error) in
            
    // my_app_user_id added as an alias for current user
}

[[RCPurchases sharedPurchases] createAlias:@"my_app_user_id" completionBlock:^(RCPurchaserInfo *purchaserInfo, NSError *error) {
    
    // my_app_user_id added as an alias for current user
}];

Purchases.sharedInstance.createAlias("my_app_user_id", ::showError) { purchaserInfo ->
  // my_app_user_id added as an alias for current user
})

Purchases.getSharedInstance().createAlias("my_app_user_id", new ReceivePurchaserInfoListener() {
  @Override
  public void onReceived(@Nullable PurchaserInfo purchaserInfo, @Nullable PurchasesError error) {
    // my_app_user_id added as an alias for current user
  }
});

In practice, using the .createAlias() method usually looks something like the following:

1. User opens the app, Purchases is instantiated without an App User ID therefore generates a random App User ID
2. User creates an account later
3. Developer calls createAlias(newAppUserID) to link any previous purchases to newAppUserID in RevenueCat

Now the subscriber can be referenced in the Purchases SDK or the REST API by using the developer specified App User ID.

Restoring Purchases

Restoring purchases is a mechanism by which your user can restore their in-app purchases, reactivating any content that had previously been purchased from the same store account (Apple or Google).

If two different App User IDs try to restore transactions from the same underlying store account (Apple or Google) RevenueCat will create an alias between the two App User IDs and count them as the same user going forward.

This is a common if your app does not have accounts and is relying on RevenueCat's random App User IDs.

Purchases.shared.restoreTransactions { (purchaserInfo, error) in
    //... check purchaserInfo to see if entitlement is now active
}

[[RCPurchases sharedPurchases] restoreTransactionsWithCompletionBlock:^(RCPurchaserInfo *purchaserInfo, NSError *error) {
    //... check purchaserInfo to see if entitlement is now active
}];

Purchases.sharedInstance.restorePurchasesWith(::showError) { purchaserInfo ->
    //... check purchaserInfo to see if entitlement is now active
}

Purchases.getSharedInstance().restorePurchases(new ReceivePurchaserInfoListener() {
	@Override
	public void onReceived(@android.support.annotation.Nullable PurchaserInfo purchaserInfo, @android.support.annotation.Nullable PurchasesError error) {
    //... check purchaserInfo to see if entitlement is now active 	
  }
});

try {
  const restore = await Purchases.restoreTransactions();
  // ... check restored purchaserInfo to see if entitlement is now active
} catch (e) {

}

Purchases.restoreTransactions(
  info => {
    //... check purchaserInfo to see if entitlement is now active
  },
  error => {
    // Error restoring purchases
  }
);

var purchases = GetComponent<Purchases>();
purchases.RestoreTransactions((info, error) =>
{
    //... check purchaserInfo to see if entitlement is now active
});

try {
  PurchaserInfo restoredInfo = await Purchases.restoreTransactions();
  // ... check restored purchaserInfo to see if entitlement is now active
} on PlatformException catch (e) {
  // Error restoring purchases
}

Sharing Subscriptions Across Store Accounts

RevenueCat allows you to choose whether or not users may reuse a subscription from an App or Play Store account that already has that subscription active.

By default, allowSharingAppStoreAccount is True unless the Purchases SDK is configured with an App User ID.

Calling restoreTransactions will always create aliases, even if allowSharingAppStoreAccount is False. If you have your own login system and always set the App User Id, your user authentication system should be used to restore purchases.

When a user logs out you should call the reset() method on Purchases to reset the App User ID to a new generated App User ID. This sets you up with a new anonymous user for the logged out state.

App User IDs Should Not Be Guessable

RevenueCat provides subscription status via the public API, having App User IDs that are easily guessed is not good. It is recommended to use a non-guessable psuedo-random ID that isn't made public inside your app.

For App User IDs generated by RevenueCat, we use a UUID.

Don't set emails as App User IDs

For the above reason, and GDPR compliance, we don't recommend using email addresses as App User IDs

• If you're using Firebase, see our sample resource on syncing Firebase User Ids with RevenueCat
• If you're moving to RevenueCat from another system, see our guide on migrating your existing subscriptions
• Once you're ready to test your integration, you can follow our guides on testing and debugging