Skip to main content
Solved

Create a `staging` project for staging versions of our apps and test subscriptions, offerings etc

  • 19 July 2022
  • 5 replies
  • 1009 views

@ryan You mentioned in this thread :

 Some developers choose to create multiple RevenueCat apps for different environments of the same bundle ID as well.


I just wanted to check - if we want to have a staging setup to go with our apps staging environment that means we can test new products/entitlements/ offerings etc without affecting our Production apps - given the above detail we could effectively just :

- Create a new Project (and suffix it’s name with STAGING for example) 
- Define our apps again using the same bundleids/package names 
- Setup products/entitlements/ offerings etc and test them independently of our Prod apps because we would have a new unique API key

Is that a valid way to essentially duplicate what we have for a staging setup?

Are there any settings we should not re-use from our Prod Project or can it essentially be duplicated?

Hope that makes sense, if you need more detail please let me know

5 replies

tina
Rank
Userlevel 5
Badge +10

Hey @Gazp 

This is a valid way to duplicate your production app into a staging environment! You can create a complete copy of your production app. One thing to note here is to be extra careful to not accidentally switch your production and staging API keys. For example, if you are testing in development mode with staging API keys, be sure to change this before releasing a new app update to the stores. 

Aideen Nasirishargh
Userlevel 2
Badge +4

While the proposed solution is an unblocking workaround, I was wondering if you have any plan to allow a “dev/staging” webhook URL for “env:sandbox” notifications, just like what Apple does.  It would definitely help a loooooot during the integration phase.

The problem with having two projects is that managing the packages and products will be very tricky.  AFAIK certain stores doesn’t allow having “test products” so the real product_ids should be used for both projects.  As a result of that, one can easily mistake prod for sandbox while modifying products which will have serious consequences.

So, any chance to put support for sandbox webhooks on the roadmap?

 

tina
Rank
Userlevel 5
Badge +10

Hey @Aideen Nasirishargh 

We definitely hear you! We do have plans to improve webhooks on the roadmap and this is actually one of the changes that we’re considering. We appreciate your feedback here and understanding more about your pain points! 

J
Userlevel 2
Badge +7

Is this true? I set up a staging environment and now I’m unable to fetch some of my subscriptions. Do you use the same shared app specific secret?

O
Badge +4

While the proposed solution is an unblocking workaround, I was wondering if you have any plan to allow a “dev/staging” webhook URL for “env:sandbox” notifications, just like what Apple does.  It would definitely help a loooooot during the integration phase.

The problem with having two projects is that managing the packages and products will be very tricky.  AFAIK certain stores doesn’t allow having “test products” so the real product_ids should be used for both projects.  As a result of that, one can easily mistake prod for sandbox while modifying products which will have serious consequences.

So, any chance to put support for sandbox webhooks on the roadmap?

 

Agreed, certainly would be helpful. We put up an AWS lambda function as a proxy in between to read the field environment from the webhook request JSON body and pass it on to our staging/production environment accordingly. Works great as a temporary workaround.

Reply


Terms & ConditionsCookie settings