Webhook of the week - Dwolla
I’ve completed integrations for many e-commerce webhook sources as you’ve learned from past articles. Dwolla was a great next choice, especially for their developer focus that pairs well with our focus here at Hookalu.
It’s somewhat unusual that they don’t provide dashboard access to manage webhooks, but I think it does make sense in the context of their developer orientation. Their API does provide excellent control of your webhooks.
Unlike most webhooks APIs, you must first get an access token using your app key and secret before making the HTTP POST/DELETE method calls for creating and deleting webhook endpoints. Be sure to specify a Content-Type
of application/x-www-form-urlencoded
when making the HTTP POST request for a token. Also be sure to use the base URL for either the sandbox or production accounts.
Creating and deleting webhook endpoints can now be performed using the token you just acquired. Similar to token creation, you must set the Content-Type
and also the Accept
headers to Dwolla’s custom JSON media type application/vnd.dwolla.v1.hal+json
. Most webhook APIs will return an ID you can use to create the URL for the HTTP DELETE request, but Dwolla takes more of a link approach and responds with the full URL for you in the Location
header.
This same link approach is also used in their payloads. You’ll find full URL endpoints for getting details on related event resources, rather than individual fields regarding the event. This is not very typical, but very much in line with their API design approach. I do wish they provided a list of all possible event types (topics) in their documentation.
Dwolla provides both unique event IDs and timestamps to help with idempotency handling. They also provide HMAC SHA-256 payload signatures using a shared secret you provide when creating the webhook endpoint. Overall Dwolla provides nice developer control of webhooks along with good security and idempotency features.