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("PUBLIC_SDK_KEY", {
    customerUserId: "YOUR_USER_ID"
});

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.

try {
    await adapty.identify("YOUR_USER_ID");
    // successfully identified
} catch (error) {
    // handle the error
}

Request parameters:

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

Logging out and logging in

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

try {
    await adapty.logout();
    // successful logout
} catch (error) {
    // handle the error
}

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

Assign appAccountToken (iOS)

appAccountToken is a UUID that lets you link App Store transactions to your internal user identity.
StoreKit associates this token with every transaction, so your backend can match App Store data to your users.

Use a stable UUID generated per user and reuse it for the same account across devices. This ensures that purchases and App Store notifications stay correctly linked.

You can set the token in two ways – during the SDK activation or when identifying the user.

// During configuration:
adapty.activate("PUBLIC_SDK_KEY", {
    customerUserId: "YOUR_USER_ID",
    ios: { appAccountToken: "YOUR_APP_ACCOUNT_TOKEN" },
});

// Or when identifying users
try {
    await adapty.identify("YOUR_USER_ID", {
        ios: {appAccountToken: 'YOUR_APP_ACCOUNT_TOKEN'}
    });
    // successfully identified
} catch (error) {
    // handle the error
}

Set obfuscated account IDs (Android)

Google Play requires obfuscated account IDs for certain use cases to enhance user privacy and security. These IDs help Google Play identify purchases while keeping user information anonymous, which is particularly important for fraud prevention and analytics.

You may need to set these IDs if your app handles sensitive user data or if you’re required to comply with specific privacy regulations. The obfuscated IDs allow Google Play to track purchases without exposing actual user identifiers.

// During configuration:
adapty.activate("PUBLIC_SDK_KEY", {
    customerUserId: "YOUR_USER_ID",
    android: { obfuscatedAccountId: 'YOUR_OBFUSCATED_ACCOUNT_ID' }
});

// Or when identifying users
try {
    await adapty.identify("YOUR_USER_ID", {
        android: { obfuscatedAccountId: 'YOUR_OBFUSCATED_ACCOUNT_ID' }
    });
    // successfully identified
} catch (error) {
    // handle the error
}

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.