Multiple projects and server notifications: do they automatically get routed?

  • 8 August 2023
  • 2 replies

Badge +7

Looking at option 3 in this post, it seems to be implying that if I create two RevenueCat projects for the same app, the webhook requests would be directed to the correct endpoint (production vs staging) all based on the project public API key used at the time of purchase (or other action). Is this correct? 

Since Google doesn’t really have a different server notification pubsub based on environment and apple is purely based on prod vs sandbox transactions, how does RevenueCat route the webhook requests to the correct endpoint?


Best answer by sharif 10 August 2023, 20:57

View original

2 replies

Userlevel 5
Badge +9


Yes, that is correct, your public API key is what steers your SDK requests to one of your projects. In that sense, you can almost think of your staging project’s API key as a “sandbox” key, and your production project’s API key as a “production” key. (This distinction doesn’t actually exist in real life, you just have to be careful about which API key you use in which build to make sure staging purchases don’t land in your production project or worse, production purchases don’t land in your staging project.)

Google Pub/Sub and Apple S2S notifications (I’ll refer to both of these as platform server notifications) use a completely different system. Whether a RevenueCat project receives a notification from them is purely based on whether you choose to connect that service to RevenueCat. So if you connect your Google Pub/Sub to your production project, that project will receive all Google Pub/Sub notifications, including sandbox notifications. Same with Apple.

But there is a workaround for your specific case here. Rather than ingest the notification as is, RevenueCat uses platform server notifications as notifications to refresh a purchase that we have in our systems. The flow looks a little like this:

  1. Google charges a user to renew a subscription.
  2. Google sends a notification via Pub/Sub with that subscription’s info to RevenueCat.
  3. RevenueCat notes the subscription’s unique identifiers and checks if we have that subscription in our system.
  4. If not, we ignore the notification.
  5. If yes, we refresh the subscription via Google’s API endpoint. Note that we do not rely on the notification for the subscription details, we always go back to Google’s APIs.

As you can see, step 4 is key. With your setup, your production project will only have production purchases, while your sandbox setup will only have sandbox purchases. So, if you connect platform server notifications to your production project, it’s true that notifications for sandbox purchases will be sent to the production project. But, since your production project doesn’t have any sandbox purchases in it, it will simply drop any notifications for sandbox purchases. Likewise with your sandbox project, it will drop production purchases.

So, in conclusion, you don’t have to worry about platform server notifications mixing your two environments together. Just make sure you remember to change your API keys when releasing a production build!

Badge +7

Thank you for such a thorough response! If I’m understanding this correctly, if a site were to use auto-indexed user IDs (which is truly an anti-pattern these days), it could cause an issue because users on staging & production could have the same ID. However, if the servers use UUIDs (as is generally recommended), it should work seamlessly because RevenueCat will ignore server notifications for users who’s IDs are unknown.

In my case we use UUIDs, so it sounds like this should work.