Skip to main content
Question

Web hooks & REST API

  • 4 January 2023
  • 2 replies
  • 735 views

Hi,

Im trying to keep my database in sync with each users current state.

Webhooks

First I tried to use web hooks data but I ran into multiple issues:

  1. The basic event from the documentation (above all other examples like initial purchase) has way more fields like a real promo code event.
  2. Im not sure what user ids to compare. original_app_user_id, app_user_id especially with use cases like “restore subscription”. The documentation calls for comparing original_app_user_id but isn't it wrong in cases of restore and to prevent to be both users entitled here?
  3. “expiration_at_ms” is not under entitlement_ids like in the REST API, is this not the entitlement expiration date? Thats because another event for the same app_user_id returns a not migrated state but just for example for the new purchase and I have to store all events right?

I think there should be a way simpler web hook.

  • RevenueCat detect a new event but instead of sending it, it checks the user state, do all the work and send the current state of the user back.
  • In case of transfers or anything similar RevenueCat sends multiple events for the users to bring them all on the current state.
  • The documentation needs some work for using web hooks, what Ids to compare in order to update the current state for each user (probably the most used case).

REST API

I could call the REST API on each web hook event to get the latest subscription status. This one expects the app_user_id what is provided by almost all events except “Transfer”.

“Transfer” is providing multiple “from” and “to” ids and again and this point I don't know what to do to sync both users.

  1. Should I call the REST API for all ids except the anonymous?
  2. What about delays on the web hook delivery? Does platform channel fix this or do I have to call from my frontend at least for purchase events to ensure the user can access the premium features instantly?

 

I really like the frontend integration but its quite a challenge to implement this in both of the available ways to work in call cases and Im blocked at this point.

Hey Sergej!

I believe we answered some of these questions in a support ticket, but I wanted to answer here as well for any questions missed, as well as for visibility that could help other developers. 

Webhooks

  1. Each event will be a little different - for example, Product changes have a "new_product_id", grace periods have "grace_period_expires_at", etc. The sample events listed on our website are a good place to start but it’s worth bearing in mind that an event may have additional fields not shown there, or may be missing a field not relevant to that event. 
  2. Webhook events will have an aliases array - you can either choose the ID which is best for you, or it's good practice to save all of them as well. This is safe to use with transfers and restore purchases as well.
  3. The REST API includes both an expiration in the subscription object, and the entitlement object. Within the webhook, the `expiration_at_ms` field will be specific to that particular transaction. It could change, like for example if the user cancels

REST API

  1.  We talk about using the API and webhooks together to create a system to sync the customer status in our docs here: https://www.revenuecat.com/docs/webhooks#syncing-subscription-status
  2. In order to cut down on delays, we recommend apps respond quickly and then defer any processing until after the response has been sent. We will also retry to deliver webhooks up to 6 times. The SDK itself also receives an API response from RevenueCat when purchases are made, so you could potentially use that as well, either by honoring the purchase based on the SDK response until your backend can verify with RevenueCat, or by having the app notify your backend of a purchase so that you can verify it.

Update: Im waiting for the new webhook implementation. 

Reply


Terms & ConditionsCookie settings