Hey @bbcat  ,

1. There is a new type EXPIRATION. The relevant subscription is terminated with this request. This means that all subscriptions that are no longer renewed will also be terminated by RevenueCat at the end of the subscription. As a result, we no longer have to worry about the termination on the backend side, regardless of the reported digital end date (“expiration_at_ms”). Is this assumption correct for iOS and Android?

Yes your assumption is correct our EXPIRATION webhook event should happen shortly after an expiration, but there can be delays.

2. We have a relatively large number of requests PRODUCT_CHANGE that do not result in a subscription extension, not even in RevenueCat. Several such requests can come in succession without anything happening. What exactly is the purpose of the PRODUCT_CHANGE request?

PRODUCT_CHANGE is just a notification a user has changed their product. This event doesn’t necessarily correspond when someone’s new subscription will start, just letting you know they have. Often developers ignore these unless you need to change something on our backend or need to know the product that the user is changing from.  

3. We are also facing the issue that PRODUCT_CHANGE and RENEWAL webhooks are not always sent in the same order to our backend system. Is this an issue on your side or is this possible to happen and we need to take care of it?

We can’t guarantee that PRODUCT_CHANGE  or RENEWAL webhooks will be sent in the same order. With that said, all of the information in the webhooks should be accurate. 

Let me know if you have any additional questions regarding our webhooks!