Hey all, I’m Zack, a product designer on Workbench!
We’ve heard feedback during the beta that webhook endpoints are harder to manage in Workbench when compared to the previous developer dashboard experience. We’ve read every piece of feedback that y’all have given us, and we’d love to share some of the updates we’re exploring!
Webhooks overview
We’re exploring more of a traditional management screen with a high level view of how your endpoints are performing.
Updated webhooks overview tab
Grouping related event deliveries and a chronological list
We’re also exploring a new list view to show which deliveries have failed, are failing, or have recovered. Additionally, we’re thinking about bringing back the chronological list of deliveries and introducing simple indicators to show you which deliveries are related to each other. You’ll be able to quickly toggle between either of these views without losing context.
Grouped event deliveries
Chronological list of deliveries
Any feedback is welcome, but we’re most keen to learn:
- What key pieces of information do you need to manage webhook endpoints and event deliveries effectively? (that might be missing or hard to find in the proposed design)
- Is there anything that’s surprising or confusing about the new grouped deliveries view?
- What information would you expect to see under the Endpoint Configuration tab?
Thanks again for being part of this community and we’re really excited to share more early work with y’all!
-Zack
6 Likes
It might be nice to be able to create a webhook from the Event Details, which can be viewed in the Events tab. With this, you can first research which events you want to use in the Events tab and then move on to creating the endpoint.
Of course, there may be cases where you want to register an event other than the ones specified. So it would be better if you could switch to a different event based on the current creation form.
Hey Hidetaka! Thanks for the response!
We’re actually looking at making some improvements to the event list page as well, one of which is being able to create an endpoint right from that view.
This screenshot is still work in progress, but you can see some of the direction we’re exploring.
1 Like
Fantastic !
I can’t wait to try the updated UI 
1 Like
Nice improvement!
If there is a way to see all the events that are NOT being used, but are added to the webhook, plus an easy way to remove them… genuis.
1 Like
Hey Jay, welcome to Insiders and thanks for the response!
Great feedback and definitely something that we want to explore–you’re not alone with this feedback!
+1 to Jay’s idea.
And additionally, what do you think about adding “solution/use-case based presets” to the new webhook creation form?
We are documenting best practices for Webhooks for each business model:
If we provide use-case based presets, it would make it easier for developers to get started with using Webhooks.
For example:
- Subscription preset:
customer.created / customer.subscription.created / …
- E-commerce preset:
payment_intent.created / checkout.session.completed / …
We’re definitely thinking about this as well! We’re working through what the logical groups of events would be, but definitely something we want to do. Here are some early concepts I’ve been exploring (copy is all placeholder)!
Z
1 Like
That’s amazing!
I’d like to dogfood this feature
These are all excellent improvements. I’ve had to disable the workbench beta since we couldn’t find our information as easily, but these improvements are a step in the right direction. I’ll re-install it in the coming weeks. I found several features in the workbench beta to be a vast improvement, but when I reviewed it for daily use, it was missing the most relevant meat-and-potatoes info that was so easy to find in the legacy version. This all looks GREAT!
1 Like
Thanks for the feedback @bensontrent! Great to hear that we’re moving in the right direction with these updates!
I’d love to hear more about the relevant info that was missing from Workbench–definitely want to make sure we’ve got that in there!
-Z
I did an extensive review with your feedback team. I got to see your new beta improvements. The one essential thing I offered was a recommendation to add more color to the status badges. Status “200” in grey does not give immediate positive feedback. Adding some color will allow the end-user to understand the issue without reading.
This was my proposal. A more elegant solution would be welcome, but the color-feedback is essential:
The most critical information when looking at webhooks is the server response. In the legacy interface, we can see this information without clicking.
Great feedback @bensontrent ! This should be currently implemented if you wanted to check it out and let us know what you think!
Thanks!
Excellent job; the new status badges are very helpful.
I’ll keep Workbench on for one of my Stripe companies and let you know if I see further areas for improvement. Thanks, Team!!!
1 Like
One critical issue that makes Workbench less helpful than the legacy version is the server response is hidden…behind a button…a button that is not immediately apparent is a button.
In the place of this, and I can not restate this enough: when a webhook fails, the MOST IMPORTANT information a developer would want to see is the server response.
I would promote the server response to replace the faux button. The server response should appear on the same screen as the request body (similar to the legacy version). As a developer, if a webhook fails, this is the only information I’m looking for. Missing this information behind a button (that I didn’t know was a button) was the primary reason I uninstalled workbench: I simply couldn’t find the information I needed to workshop my bug.
We’re definitely looking at fixing this in the new webhook updates, here’s the direction we’re heading!
We would prioritize event deliveries as the default view when looking at a webhook endpoint (instead of the endpoint details/overview), and deliveries would be presented in a flat chronological list, thus presenting the response data higher up. We’re still doing some small adjustments to these updates, so this might not be exactly what lands, but it will be close.
One thing that I would love your thoughts on, in these updates we’re trying to make a clearer separation between the event and the event delivery, and one thing we’re thinking about is reducing the amount of information about the event itself from this view. We would still keep the event ID as a way to view more event information via the event view, but information like the event origin date, the event description, the API version, and the event data would be removed from this view. I’m curious if the original event information is still helpful at this level when debugging, or would it be secondary or altogether unnecessary?
Yes! I love the new beta version with the Response data front-and-center. That is excellent. Here’s my user story to help you sell this idea to your team:
In the new interface, I can see how events are grouped by ID. However, looking back at the legacy interface, you can see how helpful our response information from the server is. This is the key data we’re looking for. We have a long-running process that often times out by the 30-second time limit set by Stripe webhooks. You can see here that a customer deleted a subscription, and the request failed with a timeout.
Some background: In our backend, when we receive a request for a subscription delete event, it kicks off a multi-step API call to multiple providers to deactivate a customer’s SIM card so they can’t receive data on their subscription. We know this process may time out, so we rely on Stripe to retry it after a minute to pick up where it last timed out. You can see in the legacy version that clicking on an event gives us immediate feedback in the server response.
I want to emphasize that seeing this data does not require a second click: all the info I need is there.
Compare this to a similar view in the new interface:
Consider for a moment which interface provides the most relevant information. I’d argue that the legacy interface makes the important data more accessible; it’s not hidden behind a secondary button ( a button that does not appear as a button).
As a new user of Workbench, I felt I didn’t see how to get to the all-important response data; I thought the data was missing. While I understand the interface now, it did not guide me into the metaphorical “pit of success.”
1 Like
To answer your question, the event ID, date, API version, and description are unnecessary, repeated information when viewing a single event. We see most of this information in the request data and event interface.
1 Like
Awesome, thanks again for all this feedback! Yeah we’re definitely going to pull a lot more of that critical information to the surface here.
Shane
21
I think this may have been covered already. But the ability to see the full URLs of the webhook would be nice, or at least prioritize showing the end of the URL compared to the beginning.
I have to click into every single webhook just to see what endpoint it’s calling.
