No TRANSFER webhook when logging in after anonymous purchase

this seems to be a common issue, i have the same problem with ios promo codes used prior to account creation.

you should write a support mail, in my case they said they can enable a 

SUBSCRIBER_ALIAS webhook (which is maybe deprecated?) and then you can manually update your backend to be in sync with revenue cat again...

!-->

​@fábio-ferreira-925142 our TRANSFER webhook event represents a purchase being transferred from one customer to another (commonly due to a “restore purchases” action being performed).

When an alias is created, both the existing and new App User IDs point to the same underlying customer. This means that the purchase remains associated with that same customer.

Regarding the recommended way to keep your backend in sync, our webhooks documentation has some advice on this:

Webhooks are commonly used to sync a customer's subscription status across multiple systems. Because different webhook events contain unique information, we recommend calling the GET /subscribers REST API endpoint after receiving any webhook. That way, the customer's information is always in the same format and is easily synced to your database. This approach is simpler than writing custom logic to handle each webhook event, and has the added benefit of making your system more robust and scalable.

Given your requirement to update your backend with a newly created App User ID alias, one option could be:

• Make a request to your backend from your app after a user is logged in to the RevenueCat SDK with the non-anonymous App User ID
• Provide the ID to your backend in this request
• From your backend, call the RevenueCat GET /subscribers endpoint to verify the entitlements and aliases of the provided App User ID

I was using API v2, but the API v1 GET /subscribers endpoint is more useful.

I’m implementing RevenueCat for the first time, and while I’m an experienced developer, I’ll be honest: your APIs and webhooks feel messy. Each one returns different data. For example, in webhooks we always receive the original_transaction_id, which is really useful, but in both API v1 and v2 we never get that.

In API v2, if you list a customer’s subscriptions, you don’t even know the product_id. In API v1, the product_id is the key of the subscriptions array when calling GET /subscribers.

​@fábio-ferreira-925142 thanks for the feedback here. Our v1 API is generally designed to provide information to our SDK, while the v2 API is designed for more advanced server-side operations.

While both the v1 and v2 APIs provide the transition identifier for the current subscription period, they do not currently provide the original transaction ID. If you’re happy to share your use-case, I’d like to discuss this with our team.

Regarding product_id, the v2 API provides the RevenueCat product ID (e.g. prod1a2b3c4d5e). This can be used in conjunction with our GET projects/{project_id}/products API to find the store_identifier for the product

Exactly the v2 provided a internal product_id while in the webhooks the same attribute product_id is referent to the store_identifier, its a mess.
You should uniformize the names used, and provide the same information on api v2 that you provide from the webhook, things like original_transaction_id, original_app_user_id.
 

​@fábio-ferreira-925142 really appreciate you taking the time to describe these valid concerns. I’ve shared this feedback with our team.