Webhooks in the Dashboard - Creating a Developer Hub

Webhooks in the Dashboard - Creating a Developer Hub

Webhooks are an integral part of the Dwolla API—by far the most efficient method of receiving updates on events that happen within your application. One of the pieces of feedback our team took away from developers is that they wanted an easier way to manage something that is so critical to their application.

Dwolla has been hard at work making an aspect of the API a bit easier for our developers by adding webhook management tools within the Dashboard.

While this functionality is fully live in the Production Dashboard, we are still pushing updates out to the Sandbox. To view webhooks in the Sandbox Dashboard, you will want to follow this link.

View and Restart Webhooks Subscriptions

API Clients have the ability to restart paused webhook subscriptions via the Dwolla Dashboard. This gives engineering teams and even the business teams a convenient place to understand why they may not be receiving webhooks without having to manually retrieve a webhook subscription status 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 additional development effort.

Investigate and Replay 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.

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.

Wrapping it up

With the new webhook management tools within the dashboard, you can work on building out more value-add features to your application rather than having to worry about constructing a maintenance tool for your webhook subscription.

To get started, create a webhook subscription and check it out in the Sandbox, or in the Production Dashboard.

3 Likes

I was testing this in the Sandbox and it seems that when you click on an Event in the Event Log, in the panel that pops up to the right, the “RESOURCE ID” value is not actually the Event’s resourceId but rather the id of the Event itself, no? It would be useful for me if that displayed the resourceId as that’s typically the first thing I’m looking for.

Hi @abe, Thanks for reporting this issue! You are correct, it looks like it’s pulling the event ID value underneath RESOURCE ID. I’ll create a bug ticket and we’ll get that updated to properly reflect the resource ID and not the event ID.

Great! Thank you Spencer

@spencer

I really enjoy the ability to retry events and generally this view! There are two related parts that make it a bit quirky though.

If an event fails and you click to retry, the delivery attempts don’t show in any chronological order, so you’re left with searching in the list for the most recent attempt. I think this then affects the webhook summary display that shows a failed status even after the most recent attempt succeeded.

Fixing these for me, would be tremendous in my workflow!

Thanks again for your hard work and dedication to making these kinds of improvements!

  • AJ

Hi @ajarosinski, thanks for the feedback, I’ll get these improvements logged for our product team! The webhook delivery attempts should be returned ordered by date created, with most recent webhook request/response appearing first. Please let us know if you come across anything else when testing in the Sandbox!

@spencer Thanks for taking the time to check this out! I attached a screenshot from the webhook attempts in production that caught my attention.