#Mike Stop Continues-identify-test-mode
1 messages · Page 1 of 1 (latest)
Hello 👋
could you provide more context on the usecase here?
Or, as a stop-gap, block processing in staging whenever I'm listening in local dev. Otherwise the event log records tons of failed responses because db objects aren't shared across staging and local dev...
Putting your follow up message in the thread
Hi! So I'd like to cleanly handle events that are generated within local dev separately from those generated within my staging environment. Right now, the events fail in the staging env, making it difficult to parse. But this issue could easily lead to data corruption, making it difficult to diagnose errors.
I don't mind having only one dev environment on Stripe's side (test mode), but I would like to be able to filter events based on which env generated them.
I thought of using object metadata, but not every object has metadata.
Hi Mike. Taking over for hanzo. For having multiple test environments (ie. dev and staging), we recommend having multiple Stripe accounts to avoid the pain-points you mentioned with events being delivered to the wrong environment's endpoint.
And in that case, I simply don't activate them, so they're exclusively used for test data? What's the easiest way to log-into the testing account using the CLI? I'd like to listen to one account with, say, npm run dev, but otherwise default to my main account for regular calls to stripe
You're correct. You wouldn't active the accounts since they would be for test data. An easy way to use multiple accounts with the cli is to use the api-key flag: https://stripe.com/docs/cli/api_keys
This is wonderful! Thank you!!!