Skip to main content
Question

Use of /v1/subscribers/identify endpoint

Forum|alt.badge.img

Hi,

 

We are in the process of integrating RevenueCat into our project. On the desktop version of our app, we use web checkout for purchases. The purchase is always made with our generated appUserId.

 

The problem is that on web, the purchase is not linked to the anonymous appUserId created by the app when it first launches, leaving an orphan anonymous customer. Calling the /v1/subscribers/identify endpoint makes the link and unifies the behaviour across mobile and desktop versions of the app,

 

The /v1/subscribers/identify endpoint is not documented however. Is it still safe to use, or is there another recommended way to solve this issue?

 

    3 replies

    Forum|alt.badge.img+5
    • Crudyg123
    • Active Helper
    • October 11, 2026

    I'd avoid building directly against /v1/subscribers/identify without confirmation from RevenueCat about its stability.

    If you're using @revenuecat/purchases-js, there is an identifyUser(appUserId) method for this. Call it while the SDK is still using the anonymous ID, passing the same custom ID you use for checkout. It attempts the aliasing and switches the SDK to that custom ID. Calling changeUser first would lose that anonymous context.

    The important caveat is that identifyUser is marked experimental in the v1.39.1 API reference, so check your installed version before relying on it: https://revenuecat.github.io/purchases-js-docs/1.39.1/classes/Purchases.html#identifyUser

    If you already know your generated ID at launch, configuring the SDK with it from the start avoids creating the extra anonymous customer. Use that same ID for checkout and for looking up entitlements across your apps, within the same RevenueCat project: https://www.revenuecat.com/docs/customers/identifying-customers

    Also, aliasing isn't guaranteed for every existing customer. If the destination custom ID already has an anonymous alias, the login rules can leave the new anonymous customer separate. Keeping the custom ID consistent still lets you access the purchase.

    chris_perriam
    RevenueCat Staff
    Forum|alt.badge.img+6

    Hi ​@JetA1 

    /v1/subscribers/identify is used internally by the SDK’s logIn() method and shouldn’t be called directly.

    Could you provide the custom App User ID when configuring the SDK, or call Purchases.logIn() as soon as it becomes available and before starting checkout? This keeps the app and web checkout using the same customer identity.

    If that isn’t possible, please open a private support request with a link to this thread and one affected App User ID so we can review the exact flow.

    Forum|alt.badge.img
    • JetA1
    • Author
    • New Member
    • October 14, 2026

    Hi Chris,

     

    It seems that an app user id is necessary to show offerings to the user. We would like to avoid creating a user account before the user has shown an interest in purchasing a subscription. This means we need to configure the SDK with an anonymous user, and this user will be linked to our created user account after purchase.

     

    Using the REST API still works fine, it’s just that the anonymous user is never linked to the customer with the purchase. As ​@Crudyg123 explained, this actually also happens when a user signs in to an existing subscription on a new device, so it’s not actually a big issue.

    Terms & ConditionsAccessibility statement