It’s currently possible to set up webhooks that receive events from all connected accounts, but later on I’d like to fetch those same events in a list via the API.
For example, in some edge cases errors on our end have caused us to return a 200 to stripe when we didn’t actually process a webhook. A simple workaround for this is to fetch recent events on some schedule and re-process any we haven’t seen. This works great for events on our platform account, but the only way to do the same with connected accounts is to iterate each account and find all the events for that account. Not the end of the world, but I’d rather make a single API call to get all the relevant events from all accounts.
Would also be helpful if the events view in the Workbench had this option as well. It’s a go-to destination when I want to look at an example event, so picking an arbitrary account and hoping that account has one of the examples I’m looking for, can be annoying.
Hi @mike.ruhlin !
Thanks for leaving feedback on your use case! This is an unfortunate product gap.
Realistically, there are no near future plans to support seeing Connected events both in the Events API (so you can list all events from all Connected accounts with a single API call) or the Workbench Events tab. There are some challenges to providing this capability around the cardinality of events returned (some users have magnitudes of connected accounts), handling disconnections, data locality concerns, etc.
One solution we are considering is providing an events replay API, where you can, in a single API call, replay all your past event delivery attempts from your Connected Accounts. You could filter by fields like timestamp for example. If we were to provide something like this, how would you use it for your aforementioned use case, if at all? What else would you like to see in this deliveries API?
In the meantime, as a stop gap solution that works today with our product offering, you could also try these patterns:
-
Set up an Event Destination that sends all events, subscribes to *, to Amazon EventBridge. Once events are in Amazon EventBridge you can archive and replay them to your consumers to ensure all events are processed. In the background, events are stored and replayed from S3 in this pattern. Forward all events or just Connect account events to a CloudWatch Log group and you can inspect the example Connect events as needed for debugging.
-
Once you set up any Connect Event Destination, you’ll be able to inspect its event deliveries in Workbench using the Event Destination tab and clicking into that destination. Of course there are noticeable limitations as compared to the Events API: there’s no API support, no event type filter support, and you’ll need to set up the event destination beforehand.
Thanks for the feedback. I’m talking with our account rep now to get access to the Event Destinations, which is our ultimate goal. We’re currently in the middle of building a new integration that will use Event Destinations, while our existing product will continue running on webhooks until we get around to upgrading it.
Good to know about the replay API, as that would also help our scenario in the current product (provided replaying all those events at once doesn’t produce too much load). Instead of fetching all events, we could very easily just prompt y’all to re-send them.
The other use case we have for this is testing environments. Sometimes people experiment on those and break them for multiple days at a time, at which point stripe sends us an email complaining about webhook failures to that endpoint. Usually whoever is on-call just responds by disabling webhooks for that environment and nobody remembers to turn them back on. Then somebody uses one of those environments for testing and we have to remember to turn webhooks on, after we’ve already missed some. So the need to replay events to those environments after we re-enable them has been a bigger deal.
Perfect, I’m also the Product Manager for Event Destinations and am currently in the process of enabling it in your account, so I’ll follow up with you soon regarding that.
Thanks for the additional context as I can see how helpful replaying would be for these test environments after downtime. We actually automatically disable any endpoints that we can’t send successfully after we send you that email by the way. This might reduce some burden on your on-call engineers.
We will consider these use cases as we explore supporting programatic replaying (:
@mike.ruhlin Hi mike – wanted to follow up on this thread. We are starting to design a replay API for your events. Would you be open to chatting with me regarding your use case? Would love to input this into the design.
If so, please book some time here: GoodTime.io Meet