I’m planning two create two RevenueCat projects, one for production and one for staging, (as recommended in the quickstart), but how do people differentiate the server notifications between servers? Some of our backend APIs depend on the user’s subscription status so we save this to the respective DB.
One option would be to always tie sandbox and staging together. However, this breaks as soon as we want to use a Testflight app in production.
Another idea I had was to prefix the user ID with the environment name. Then have the Apple/Android server notifications go to my server, read the user ID, then proxy the request to the correct RevenueCat project, which will finally call the correct environment webhook. However, this seems like a lot of moving parts.
How do other people do this?
Best answer by sharif
Hey Jeremy,
The simpler way to do this would be to check the is_sandbox property of the subscriptions object from our API. TestFlight shows as is_sandbox=true. Then in your app, if it’s a debug or TestFlight build, look for subscriptions with is_sandbox=true, and if it’s a production build, look for is_sandbox=false.
Your workarounds would work but I agree that’s quite a lot of code to keep track of. Alternatively, you can create separate RevenueCat apps for sandbox, TestFlight, and production all with the same exact configuration. The only thing that would change in your app is the API keys used. When you build for TestFlight, change the API key to your TestFlight app, when you build for production, change the API key to your production app, etc. The risk is that you forget to change these keys when creating your various builds. You may be able to automate this in some way using pre-build script steps.
The simpler way to do this would be to check the is_sandbox property of the subscriptions object from our API. TestFlight shows as is_sandbox=true. Then in your app, if it’s a debug or TestFlight build, look for subscriptions with is_sandbox=true, and if it’s a production build, look for is_sandbox=false.
Your workarounds would work but I agree that’s quite a lot of code to keep track of. Alternatively, you can create separate RevenueCat apps for sandbox, TestFlight, and production all with the same exact configuration. The only thing that would change in your app is the API keys used. When you build for TestFlight, change the API key to your TestFlight app, when you build for production, change the API key to your production app, etc. The risk is that you forget to change these keys when creating your various builds. You may be able to automate this in some way using pre-build script steps.
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.
