dge_webhooks

[hasty dove]

👋 Welcome to your new thread!

⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.

🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1291479094818766900

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

[exotic onyx]

Hi there 👋 tracking metadata on Events is really tricky, especially as in most cases metadata isn't copied from the object where you place it to related objects.

Can you tell me a bit more about what environments you have comingled on a single endpoint?

[balmy fog]

so within stripe there's only two environments: live & test mode; within the live environment we current only have webhooks for prod, but we would like to add webhooks for qa. problem here would be that whenever an event occurs, stripe would send it to both the prod & qa servers but these environments share a database and we would like to avoid duplicate updates to the same database

if this makes sense

[exotic onyx]

We introduced sandboxes recently to give you the ability to create more environments rather than just live and testmode:
https://docs.stripe.com/sandboxes

but we would like to add webhooks for qa
I'm not sure I understand. These endpoints wouldn't be listening to your livemode events would they? You'd create the endpoint in testmode so it listens to testmode events, or I misunderstanding?

[balmy fog]

the qa endpoint would be listening for livemode events because this enviroment is the most production-like and thus would use the prodction database

[exotic onyx]

I'm not sure I'm grasping what you're describing. If it's listening to production events and updates the production DB then it sounds like a production endpoint rather than QA.

[balmy fog]

I mean we call it QA but yes it's technically a production endpoint

[exotic onyx]

So what kind of filtering do you want to do then? It sounds like that endpoint would need to listen to everything.

[balmy fog]

I guess another way to explain it is imagine the following setup, event A is triggered by a purchase on the A-dev server but the event will be sent to all endpoints, how does the A-dev server recognize that this event A was triggered by a purchase made on that server

[exotic onyx]

It can't.

You can try adding metadata or other defining characteristics so you can track where your request that triggered the creation of an event originated from, but it's hard to distinguish them otherwise.

Because you can have many servers that use one stripe account that then pushes events to many endpoints.

You could sandboxes to create separate environments so you can break up that many:1:many relationship though.

[balmy fog]

I see, are sandboxes capable of sending production events

[exotic onyx]

I'm sorry, I get really confused when you talk about dev servers making production requests. Sandboxes are essentially another Stripe account.

whoopss wrong thread, let me clean this up sorry about that!

[balmy fog]

I see, sandboxes are effectively different accounts, so it would not be able to handle production events

for our use case here, we effectively would have more than 1 production server receiving stripe webhook events but there doesn't appear to be an easy way to differentiate when server triggered the event

[exotic onyx]

It's not uncommon to have multiple servers making requests for a single Stripe account, or to have the webhook endpoints be distributed, but it is a bit unusual to want to run multiple types of flows (production vs qa vs dev) in a single mode in a single Stripe account.

[balmy fog]

sorry we're really only doing prod and qa for live events, we only call them prod and qa internally, but for your use case you may as well just call them server A and server B

[exotic onyx]

Yeah, there's no easy way to distinguish between which server created the object that triggered the Event you listen to. It's why we would recommend either splitting that traffic between live and testmode, or use sandboxes to break it up even further.

[balmy fog]

I see