Skip to main content
Answer

Webhook reliability for custom entitlement workflow

  • March 13, 2025
  • 2 replies
  • 88 views

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. 

This post has been closed for comments

2 replies

wes_clark
RevenueCat Staff
Forum|alt.badge.img+6
  • RevenueCat Staff
  • 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
  • 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.