Today we’re announcing the release of our updated Webhooks dashboard, which comes with a bunch of logging and developer improvements that will help any user better manage webhooks across their API connections with Rutter.
As the leading Universal API for Accounting & Commerce, we spend a lot of time working with our users to create the best developer experience. A lot of the improvements below are based on feedback we've heard from our customers so excited to roll these out!
The webhook tab now displays a log of all webhooks fired in the last 90 days. You can see the webhook destination URL, the connection ID, webhook type, the timestamp that the webhook was sent, and whether the webhook was successful.
If you’re looking to debug webhook issues for a specific connection, the search and filter lets you filter by date range, webhook result, webhook type, and connection ID.
The webhook dashboard now contains a set of debugging tools used for mocking or refiring mishandled webhooks. Users often want the ability to mock a webhook locally, so now the payload of every webhook is exposed as a JSON body within the Webhook Metadata view. If you missed a webhook, the Webhook Metadata view also exposes the last time the webhook was sent along with how many times the webhook was fired so you can reconcile Rutter’s webhook firing history with your internal logs. You can also manually fire a webhook to the desired URL within the Webhook Metadata view.
Multiple Webhook Destinations and Selective Webhook Filtering
One of the common issues we’ve heard from customers is getting flooded with webhooks that don’t contain information necessary for their workflow. Different types of customers also care about getting updates for different entities - if you’re a shipping and fulfillment company, you might only want to monitor new fulfillments issued, but if you’re a lending company, you would want to know when new orders and transactions are created.
To solve this problem, we’ve shipped the ability to selectively filter what webhooks are received. In the webhook tab, you can select what create, update, delete, and connection-specific webhooks you receive.
Another request we’ve heard from developers is the ability to set multiple webhook destination URLs - this allows developers to create different webhook environments (staging, sandbox, and production) or create routes to address different webhook types with type-specific handlers. Within the webhook configuration, we’ve allowed the ability to create multiple webhook destinations, which lets developers better manage the traffic and routing of webhooks they want to receive.