Hi @Wes!

Most webhooks will be delivered in near real-time, but delays are possible. Most cases this is just a second or so, but could be minutes, or in rare cases hours. For INITIAL_PURCHASES (the case you’re describing here), if the purchase was initiated in the app, the SDK would notify RevenueCat and webhook event will be dispatched. For any purchases made outside of the app (e.g: renewals, upgrades/downgrades, etc) this will be sent to RevenueCat via S2S notifications. 

To help reduce any delays, we recommend setting up Platform Server (S2S) Notifications: https://docs.revenuecat.com/docs/server-notifications 

If you’re just looking for the webhook to confirm purchase of a product, you can build redundancies in the app by pinging your servers in the purchase completion block and make a call server side to RevenueCat’s GET /subscribers endpoint to unlock any access or map the product to a specific balance to add to the account. 

Hi @tina, how to ensure it’s idempotent if the app has to call my backend to check subscription initial purchase?

When I call GET subscriber there is no information about recent transactions, it only tells me the entitlements, this is not enough because I need to add balance to users for certain subscriptions. 

Only knowing whether user has entitlement cannot prevent user from calling the backend API multiple times to add balances multiple times for a subscription initial purchase.

@Wes you may be able to use the product_id+purchase_timestamp as an idempotency key for a customers subscriptions? For non-subscription purchases there is a unique ID included in the PurchaserInfo object that should be used.

In the redundancy case you mentioned above, is there a way to translate the webhook transaction_id field (described as “Transaction identifier from Apple/Google” in the webhook doc here) into the RevenueCat unique id that is retrieved from GET /subscribers or in the PurchaserInfo object? I don’t see the unique RevenueCat id in the webhook events.

Hey @Mike!

There unfortunately isn’t a way to translate the Apple/Google transaction ID into the RevenueCat transaction ID - we’ll hopefully be cleaning this up in the next API and Webhooks versions, but those are on the mid to longer term roadmap. 

As a workaround, you may need to have the webhook event trigger an API call to GET /subscribers to get the additional information you need. I know it’s not the cleanest but should work.

Thanks @ryan, what is the effect of a refund / ‘CANCELLATION’ webhook event for a non-renewing purchase on the GET /subscribers API response? Does the nonSubscription object get updated to reflect the update?

Thank you

Yes, it would get removed from the API response