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.
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.
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!
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.
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.
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)!
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!
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:
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.
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.”
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.
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.
