Skip to main content
Solved

Webhook reliability for custom entitlement workflow


Forum|alt.badge.img

We are in the process of gradually migrating our payments flow over to RevenueCat. In fact, we may end up with a hybrid scenario for the foreseeable future (using parts of our own system, and parts of RevCat, namely for in-app purchase management).

I know the traditional way to consult entitlements is through the RC SDK, but we were hoping to be able to rely on the webhooks to update the appropriate models in our backend which currently dictate user entitlements (i.e. when to show our existing paywall).

I saw in the documentation that webhooks could take 5-60 seconds to fire after the event occurs. This is concerning to the workflow we had imagined: 1. User completes IAP, 2. We get a near-immediate webhook event from RC which we use to update our database, 3. All future requests from that user are no longer blocked by our paywall (based on our own logic consulting our own database).

Is this bad practice? Is the surest / fastest way to get this information to consult RC SDK for it? If the user tries to load the next page after purchasing but the webhook hasn’t fired yet, could we instead consult RC’s customerInfo API endpoint (aka, would this reflect the new entitlement state sooner than the webhook’s firing)?

Best answer by wes_clark

Hi! In this case, I would recommend using the SDK in order to verify the purchase immediately after it happens. It will be the fastest way to get the information. 

View original
Did this post help you find an answer to your question?
This post has been closed for comments

2 replies

wes_clark
RevenueCat Staff
Forum|alt.badge.img+6
  • RevenueCat Staff
  • 296 replies
  • Answer
  • March 19, 2025

Hi! In this case, I would recommend using the SDK in order to verify the purchase immediately after it happens. It will be the fastest way to get the information. 


Forum|alt.badge.img
  • Author
  • New Member
  • 1 reply
  • March 25, 2025

Ok, then it sounds like the webhook is not a reliable enough source to give the near-instant answer we need. We will retool our logic to rely on the SDK for this answer. Thanks.


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings