Skip to main content
Question

Should I rely on both webhooks and the API for latest purchases?

  • October 28, 2025
  • 1 reply
  • 46 views
U
Forum|alt.badge.img

Hi team đź‘‹

I’m using RevenueCat for both subscriptions and consumable credits.
My backend receives webhook events, and the frontend/flutter has a listener which when gets triggered  calls getUserProfile() (which hits the be endpoint which calls RevenueCat API) whenever the user opens the app.

I want to make sure my backend always has the latest purchase info instantly, even if a webhook is delayed or missed 

Should I:

  1. Use both webhooks and the RevenueCat API (as a fallback) to sync the latest transactions?

  2. Always update the stored store_transaction_identifier based on the latest transaction from the purchases associated with customer API?

Just want to confirm the best practice to ensure no missed updates across subscriptions and one-time purchases.

Thanks!

This post has been closed for comments

1 reply

chris_perriam
RevenueCat Staff
Forum|alt.badge.img+6
  • chris_perriam
  • RevenueCat Staff
  • October 30, 2025

We recommend that your backend calls our GET subscribers API for a specific customer when a new webhook is received for that customer:

Syncing Subscription Status

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.

Source: https://www.revenuecat.com/docs/integrations/webhooks#syncing-subscription-status

From the same page:

RevenueCat will send POST requests to your server, in which the body will be a JSON representation of the notification. Your server should return a 200 status code. Any other status code will be considered a failure by our backend. RevenueCat will retry later (up to 5 times) with an increasing delay (5, 10, 20, 40, and 80 minutes). After 5 retries, we will stop sending notifications.

If you're receiving a webhook it's important to respond quickly so you don't accidentally run over a timeout limit. We recommend that apps defer processing until after the response has been sent.

 

Given that RevenueCat will reattempt each webhook that fails to deliver, the risk of missing one should be low. You may wish to keep a record of the User IDs contained within the webhook events you receive. If there is an issue with your webhook processing, you’d then be able to call our API for each of the relevant User IDs to fetch the latest information directly from our servers.

Regarding your question about updating the store_transaction_identifier stored in your backend - I’m not sure what the purpose of doing so would be. This identifier is specific to a transaction, and a user may have multiple transactions. For example, a user may have an active subscription and also make a consumable purchase. Despite the active subscription being an older transaction, it would likely still be relevant to your application.

Hope this helps! Let me know if there’s anything I can clarify further

Terms & ConditionsCookie settingsAccessibility statement