The interesting thing about being a part of product/engineering for an extended period of time is to see the evolution of a product with a relatively small feature set grow to be one critical to the success and efficiency of our clients, built for multiple audiences with different requirements.
In the beginning, the Dwolla Dashboard was created to allow clients to see certain information that their business operations might need to help their end users (e.g. user details, transactions, business trends, etc.). Clients have asked for this functionality to be easily accessible via the Dwolla Dashboard, outside of being able to access the same information via the Dwolla API. Because of these requests, we realized that while this information is available, the needed development takes a back seat to the development of their end user’s functionality.
Over the years we have added multiple features and functions to the Dwolla Platform and Dwolla Dashboard, but the theme continued being very focused on business operations. Recently, we began collaborating about what highly valuable information we could expose to our Clients that was already accessible in our API and would bring the most value to our Clients’ everyday activities. This is when the topic of webhooks and how we could increase the ease of access to them came into the picture.
Not just webhooks, but the subscriptions, events and status of these webhooks. What if we could not only show information about a subscription and its webhooks, but could streamline efforts of viewing this information, much like we did with customers and transactions? This fits into our playbook of providing functionality via our dashboard that many clients don’t program for, but it is for a totally different audience. We questioned ourselves, asking if our Clients’ engineering teams would even want this information and functionality.
So, as good product teams do, we asked our Clients. The universal answer was a resounding, “Yes!”
As it often happens, when you expose an underlying need it can lead to many tangential and important findings that could indeed be more valuable than the original idea. That was certainly the case with this project. Unexpected but useful ideas that emerged from our research included:
Easily Restart Webhooks Without Development
Clients have the ability to restart a paused webhook subscription via the Dwolla Dashboard.
This helps engineering teams understand why they may not be receiving webhooks without having to pull down the information from the Dwolla API. Additionally, once the issue for the failed webhooks is resolved, clients are able to restart the webhook subscriptions via the dashboard without any development effort.
Easily Investigate Webhooks
Being able to find specific webhooks by topic, resource ID, date, status or end user creates a more painless experience in identifying any points in question.
In order to be really helpful, Dwolla Dashboard users would ideally be able to filter and segment the webhooks into logical chunks of information, in which we look forward to iterating on in the upcoming weeks.
Conveniently Retry Webhooks
Being able to replay webhooks individually or en masse via the Dwolla Dashboard empowers our Clients to fix an issue much quicker than before.
Once Clients find the specific webhooks that might be having issues, they may want to replay some or all of them to kick off any of their downstream processes, which could include email notifications about a payment transfer or notification around an end user’s status.
As an agile environment we look forward to continuing to iterate in small chunks that add value to our clients and their applications.
To date, we have rolled out our webhook subscription view, the ability to restart a paused subscription and the ability to view every webook in the system. While this is only the beginning, we anticipate continuing our focus on implementing additional functionality based on the needs of our Clients, whether that be business or engineering focused.