Identify users in Android SDK

Adapty creates an internal profile ID for every user. However, if you have your own authentication system, you should set your own Customer User ID. You can find users by their Customer User ID in the Profiles section and use it in the server-side API, which will be sent to all integrations.

Setting customer user ID on configuration

If you have a user ID during configuration, just pass it as customerUserId parameter to .activate() method:

Adapty.activate(applicationContext, "PUBLIC_SDK_KEY", customerUserId = "YOUR_USER_ID")

Want to see a real-world example of how Adapty SDK is integrated into a mobile app? Check out our sample apps, which demonstrate the full setup, including displaying paywalls, making purchases, and other basic functionality.

Setting customer user ID after configuration

If you don’t have a user ID in the SDK configuration, you can set it later at any time with the .identify() method. The most common cases for using this method are after registration or authorization, when the user switches from being an anonymous user to an authenticated user.

Adapty.identify("YOUR_USER_ID") { error ->
    if (error == null) {
        // successful identify
    }
}

Adapty.identify("YOUR_USER_ID", error -> {
    if (error == null) {
        // successful identify
    }
});

Request parameters:

Customer User ID (required): a string user identifier.

Resubmitting of significant user data

In some cases, such as when a user logs into their account again, Adapty’s servers already have information about that user. In these scenarios, the Adapty SDK will automatically switch to work with the new user. If you passed any data to the anonymous user, such as custom attributes or attributions from third-party networks, you should resubmit that data for the identified user.

It’s also important to note that you should re-request all paywalls and products after identifying the user, as the new user’s data may be different.

Logging out and logging in

You can logout the user anytime by calling .logout() method:

Adapty.logout { error ->
    if (error == null) {
        // successful logout
    }
}

Adapty.logout(error -> {
    if (error == null) {
        // successful logout
    }
});

You can then login the user using .identify() method.

Detect users across devices

When the SDK is activated, it automatically reads the user’s existing entitlements from StoreKit (iOS) or Google Play Billing (Android) and syncs them with the Adapty backend. An active subscription appears on the Adapty profile without the app calling restorePurchases.

What does not happen automatically is recognizing that a profile on a new device belongs to the same user as a profile on the original device. Adapty matches profiles by Customer User ID, so identity continuity depends on what you use as the CUID.

What Adapty can detect across devices

Your setup	What Adapty detects	What you must do
Customer User ID = `device_id` (no app login)	The new device gets a different CUID and therefore a different profile. The subscription syncs to the new profile via an Access level updated event, but `subscription_started` does not fire — the new profile is treated as an inheritor of the original purchase. Analytics keyed on `subscription_started` will undercount returning users.	Use a stable account ID as the Customer User ID so a returning user matches the existing profile across devices.
Customer User ID = stable account ID (login on every device)	The SDK auto-syncs the subscription on `activate()`, and `identify()` matches the existing profile by CUID.	No additional setup needed — both identity and subscription resolve automatically.
Apple Family Sharing inheritor	The family member receives the subscription through an Access level updated event only — `subscription_started` does not fire.	Listen for Access level updated. See Apple Family Sharing for the full event matrix.
Same Apple/Google account, different in-app users	The first profile to record the purchase becomes the parent. Subsequent profiles see the subscription through an inheritor chain, with one Access level updated event.	Require login, then choose a sharing mode that fits your model.

Restoring purchases on a new device

Expose a user-initiated “Restore purchases” button on your paywall. Apple App Review (guideline 3.1.1) requires one, and it acts as a fallback when the automatic sync misses an edge case. The button should call restorePurchases on your SDK.

A programmatic restorePurchases call on first launch is not required for normal use — the SDK already runs the equivalent on activate(). Reserve programmatic calls for forcing a fresh receipt check, for example when debugging missing access after activate() completed.