RevenueCat

Build With RevenueCat

Build a customized mobile subscription business with RevenueCat. We do the heavy lifting of normalizing subscribers from any source and maintain a single source of truth for subscription status, so you can get back to building your app.

RevenueCat is a powerful, secure, reliable, and free to use in-app purchase server with global support. All you need to get started is an API key.

Identifying Users

How RevenueCat handles user identity

Suggest Edits

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.

User identity is one of the most important components of many mobile applications, and it's extra important to make sure the subscription status RevenueCat is tracking gets associated with the correct user.

The Purchases SDK allows you to specify your own user identifiers or use anonymous identifiers generated by RevenueCat. Some apps will user a combination of their own identifiers and RevenueCat anonymous Ids - that's okay!

Anonymous App User Ids

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, a new random App User ID will be generated.

Purchases.configure(withAPIKey: "my_api_key")
 
[RCPurchases configureWithAPIKey:@"my_api_key"];
 
Purchases.configure(this, "my_api_key")
 
Purchases.configure(this, "my_api_key");
 
await Purchases.setup("public_sdk_key");
 
Purchases.setup("public_sdk_key");
 
Purchases.setup("public_sdk_key");
 
See Unity installation instructions https://docs.revenuecat.com/docs/unity

Anonymous App User Ids are always prefixed with $RCAnonymous: for SDK versions 3+. This can be useful for working with anonymous users on your server.

Provided App User ID

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 have 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 configuration

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");
 
await Purchases.setup("public_sdk_key", appUserId: "my_app_user_id");
 
Purchases.setup("public_sdk_key", "my_app_user_id");
 
Purchases.setup("public_sdk_key", "my_app_user_id");
 
See Unity installation instructions https://docs.revenuecat.com/docs/unity

Set App User ID after configuration

If your app doesn't receive its own App User ID until later in its lifecycle, you can set (or change) the App User ID at any time by calling .identify(). The most common cases are users creating accounts or logging in. 

// Configure Purchases on app launch
Purchases.configure(withAPIKey: "my_api_key")

//...

// Later log in provided user Id
Purchases.shared.identify("my_app_user_id") { (purchaserInfo, error) in
    // purchaserInfo updated for my_app_user_id
}
 
// Configure Purchases on app launch
[RCPurchases configureWithAPIKey:@"my_api_key"];

//...

// Later log in provided user Id
[[RCPurchases sharedPurchases] identify:@"my_app_user_id" completionBlock:^(RCPurchaserInfo *purchaserInfo, NSError *error) {
    // purchaserInfo updated for my_app_user_id
}];
 
// Configure Purchases on app launch
Purchases.configure(this, "my_api_key")

//...

// Later log in provided user Id
Purchases.sharedInstance.identifyWith("my_app_user_id", ::showError) { purchaserInfo ->
  // purchaserInfo updated for my_app_user_id
}
 
// Configure Purchases on app launch
Purchases.configure(this, "my_api_key");

//...

// Later log in provided user Id
Purchases.sharedInstance.identifyWith("my_app_user_id", ::showError) { purchaserInfo ->
  // purchaserInfo updated for 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) {
		// purchaserInfo updated for my_app_user_id
	}
});
 
// Configure Purchases on app launch
await Purchases.setup("public_sdk_key");

//...

// Later log in provided user Id
PurchaserInfo purchaserInfo = await Purchases.identify("my_app_user_id");
 
// Configure Purchases on app launch
Purchases.setup("public_sdk_key");

//...

// Later log in provided user Id
const purchaserInfo = await Purchases.identify("my_app_user_id");
// purchaserInfo updated for my_app_user_id
 
// Configure Purchases on app launch
Purchases.setup("public_sdk_key");

//...

// Later log in provided user Id

Purchases.identify(
  "my_app_user_id", 
  info => {
    // purchaserInfo updated for my_app_user_id
  },
  error => {
  }
);
 
purchases.Identify("my_app_user_id", (purchaserInfo, error) => {
  // purchaserInfo updated for my_app_user_id
});

If Purchases is initialized with an Anonymous App User ID, then later identified with a Provided App User ID, the users will automatically be aliased together and treated as the same record in RevenueCat.

Aliasing

Aliasing is when two App User Ids get merged together and treated as the same user in RevenueCat - effectively connecting two sets of user data as one. The user can then be referenced by any of their aliases and the same result will be returned.

Aliases are needed to effectively manage identify between RevenueCat and the app stores. Since a subscription is ultimately linked to an Apple/Google account, and the stores don't provide any unique user identifier themselves, there are cases when the same store receipt needs to be associated with multiple App User Ids in RevenueCat.

You can expect aliases for the following cases:

  1. Two different App User Ids restore the same purchase receipt
  2. An Anonymous App User ID gets merged with a provided App User Id through .identify()

Logging Out

When a user logs out you should call the reset() method - this a new Anonymous App User Id for the logged out state.

Logging back in

To log in a new user, the provided App User Id should be set again with .identify().

Sharing Subscriptions Across Platforms

You can share a subscription across platforms (e.g. iOS -> Android) by identifying with the same App User ID. This is usually done through your own authentication mechanism.

Note that a user can only manage their subscription on the platform it was purchased from.

Tips for setting App User IDs

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.

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

Next Steps

Updated 3 days ago

Identifying Users

How RevenueCat handles user identity

Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.