Can I use Revenuecat webhooks in development?

  • 31 May 2023
  • 1 reply

Badge +4
  • Active Member
  • 11 replies

Some context 

I am creating an application that already has an existing web app. The web apps payments are done via Stripe. The mobile app I am building will have payments done via Revenuecat. 

I am setting a property on my user object to let me know which platform the user has used in order to pay for a subscription. 

Why am I doing this?

If they have payed using stripe on web then I need to let them have access to all premium features on the mobile app. They should not have to pay for a subscription on the mobile app as well. 

Stripe makes this very easy with their Webhooks. 

When a user subscribes, a Webhook event gets sent to the backend that tells the user object to update the subscriptionPlatform to “web”. This way I know that the user has subscribed on web, should get access to all premium features on mobile too without duplicate subscribing, and should be directed to the web app to handle anything to do with their subscription. 

Stripe also allows all of this to be tested in development. 

I need to implement the same feature but vice versa. For someone who has subscribed on the mobile app. (e.g send Webhook to backend to set user object prop of subscriptionPlatform to “android”). 

It looks like Revenuecat can do Webhooks. However, I don’t see anyway to test this in development. Which is necessary for me to ensure it all works before creating a prod version of the app.


My question is how do I test Revenuecat Webhooks in development? Is this even possible? If not then how have your users been able to get around this?





1 reply

Userlevel 4
Badge +8

Hi Jay,


We can actually keep track of your customers across web/mobile without you needing to build anything on your backend. We can get customer info from Stripe (see: and identify users in our database for you (see: So someone could purchase on Stripe, you send the purchase token to us (creating a RevenueCat user), then they login to their account on mobile, and we identify that login with their purchase history.


This can all be done in development as well with test users.