Skip to main content
Solved

Why does event data not match API data?


Forum|alt.badge.img+4

Context

For subscriptions, we have both

  • A Node.js webhook that updates subscription info for a user in our database.
  • iOS code fetching the latest purchase info with the revenue cat API. This code checks the user’s expiration date on start up.
    • Ideally, we can remove the iOS code and just rely on the webhook, but this is not acceptable as explained below...

Problem

It seems that the event data have incorrect subscription expiration dates. In contrast, the API is giving us the right date. We saw this issue while looking at the dashboard events.

  1. This user’s last received a “PRODUCT_CHANGE” event. They switched from a monthly to annual subscription using a promotion code, giving them a month trial ending on Sep 12, 2021.
  2. This event instead had "expiration_at_ms": 1628876655000, which is Aug 13, 2021. Also, the event didn’t have any promotion code data.
  3. However, the API gave us the correct date of Sep 12, 2021.
  4. The customer’s entitlements section also has the correct date, noting “Trial converts on 2021-09-12”.

Question

Shouldn’t the webhook event reflect the actual expiration date of Sep 12, 2021? Are we using the webhook correctly, or should we be syncing the data to our database differently?

Best answer by sharif

There are a few things going on here that’s creating the mismatch. It’s not an issue in RevenueCat or your app, it’s simply a complicated transaction history. Here are the relevant points to explain the behavior:

  1. The PRODUCT_CHANGE webhooks contain the expiration date of the previous subscription. This is so you can understand when the previous subscription will end: upgrades end the previous subscription immediately while downgrades keep the previous subscription through its period end. You can optionally use this date to show the user when they can expect the downgrade/upgrade to occur, but you should not use this date to figure out entitlement status. Instead, you should make a call to RevenueCat’s API to find the expiration of their entitlement.
  2. The API is returning September 12 because the API tells you the current status of the user’s entitlements. This is the correct date that you should rely on for entitlement status. You should always rely on the API as the source of truth, because the API will always eventually become up to date.

To keep PRODUCT_CHANGE webhook logic simple on your backend we recommend that you make a call to the RevenueCat API whenever you receive a notification to get up to date entitlement status information.

View original
Did this post help you find an answer to your question?

2 replies

sharif
RevenueCat Staff
Forum|alt.badge.img+9
  • RevenueCat Staff
  • 513 replies
  • Answer
  • August 27, 2021

There are a few things going on here that’s creating the mismatch. It’s not an issue in RevenueCat or your app, it’s simply a complicated transaction history. Here are the relevant points to explain the behavior:

  1. The PRODUCT_CHANGE webhooks contain the expiration date of the previous subscription. This is so you can understand when the previous subscription will end: upgrades end the previous subscription immediately while downgrades keep the previous subscription through its period end. You can optionally use this date to show the user when they can expect the downgrade/upgrade to occur, but you should not use this date to figure out entitlement status. Instead, you should make a call to RevenueCat’s API to find the expiration of their entitlement.
  2. The API is returning September 12 because the API tells you the current status of the user’s entitlements. This is the correct date that you should rely on for entitlement status. You should always rely on the API as the source of truth, because the API will always eventually become up to date.

To keep PRODUCT_CHANGE webhook logic simple on your backend we recommend that you make a call to the RevenueCat API whenever you receive a notification to get up to date entitlement status information.


Forum|alt.badge.img+4
  • Author
  • New Member
  • 3 replies
  • August 30, 2021

Thanks Sharif! I really appreciate the detailed answer. Makes sense, and good idea on the API call in the webhook.


Reply


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