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.
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.
This event instead had "expiration_at_ms": 1628876655000, which is Aug 13, 2021. Also, the event didn’t have any promotion code data.
However, the API gave us the correct date of Sep 12, 2021.
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:
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.
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.
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:
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.
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.
We use 3 different kinds of cookies. You can choose which cookies you want to accept. We need basic cookies to make this site work, therefore these are the minimum you can select. Learn more about our cookies.