[jeiting]

Would love to hear how we can improve the API to make you not want Stripe to do it better. :)

Obviously, Stripe is the gold standard and I think we have a hard time, but we're hoping to improve the developer experience even more this year.

[cyral]

My main issue is how the webhooks sometimes give incorrect info, which has led to many customer complains when their subscription gets messed up by some edge case that I would expect to be abstracted away by RevenueCat but isn't.

For example, when I implemented the PRODUCT_CHANGE event I expected it would notify me of the new product, but that is not the case on Android which led to bugs with some customers. It turns out that only iOS sends the new_product_id, so it is impossible to know from this event what the new product should be to display it in the app. Since upgrades/downgrades are immediate on Android, it turns out that the solution was just to not handle that event on Android since the renewal event would override the product anyways. (but sometimes the events came out of order, which is what led to bugs when PRODUCT_CHANGE was after RENEWAL).

There are a lot of cases where events in the dashboard are totally out of order and don't make sense, like showing a customer purchasing the lesser plan, then renewing for the upgraded plan, and then switching from the lesser to the upgraded plan 10 days later. How could that be possible? The switch should have been between the renewals, so it's very confusing to debug.

I've been told that now the recommended approach is to ignore all the webhook data, and simply call the RevenueCat API to get the entitlement and subscription status - however I asked how to parse this into something meaningful and didn't get a good answer. I would like to know the users current entitlement, and the current subscription (which can be different than the entitlement). For example, if the user downgrades, their entitlement may still be the upgraded plan for a while, but the app should reflect that they are no longer subscribed, or that they are subscribed to a different plan. For the entitlement it is easy I think, just choose the highest entitlement level to use. For the subscription, maybe choosing the last renewed one would work? But there are so many complexities with downgrades, upgrades, crossgrades I don't know if that is true. The answer from support was basically that they didn't know, yet this is an absolute must for almost any app - there has to be a way to display what the user is currently paying (or not paying) for, linking out to the native UI is not an option as it's not user friendly and cannot be displayed cross platform (I want the website to also reflect what they are paying for). My big concern with this is also, why does the API supposedly return the correct data but the webhook doesn't? If I am calling the API 10ms after receiving the webhook, why can't the webhook just deliver correct data instead?

Another current issue I discovered the other day was that grace periods are no longer working. The RevenueCat dashboard shows that they are getting a 7 day grace period (the expiration date in the dashboard is correct), yet in the webhooks I am getting the wrong expiration, one that is only a day away. Apparently this is due to a change by Google and a fix is (maybe?) on the way? But it caused a lot of issues that I didn't expect.

Basically RevenueCat's promise is great, it has saved a ton of time but isn't quite there on fully abstracting all these native edge cases away, they crop up in the API occasionally, and the proposed fix to use the API instead of the webhook data is half baked when support has no idea how to actually parse it to get the current subscription that should be displayed to the user (in the case that they upgraded/downgraded and have more than one). I love the idea but I'm hesitant to recommend it to anyone because lately it's been causing a lot of headaches with customers having billing issues due to these inconsistencies.

[jeiting]

Thanks for the great feedback. These are all legit issues. We have on our roadmap a revisiting of our API this year and I think we need to have a lower tolerance for abstraction leakage.

Would you mind dropping me an email [e-mail]? I think for our long term viability we need to have the trust of people who care about edge cases like this. I’d love to hear more.