Webhooks best practices
Review these best practices to make sure your Webhooks remain secure and work properly.Respond quickly with a 200
The webhook event handler defined on your server, when it receives a new event from Dfns, should be quick to handle it, and return quickly a200
status code to indicate that the event was indeed delivered. If your handler expects to do some processing taking longer than a few seconds, you should consider adding this to a queue for processing on your side. Otherwise the request delivering the event might timeout.
Also, your handler should catch any error that happens on your side, so it still respond with a 200
response to Dfns, indicating that you received it already, otherwise the same event might be retried a few times and fail all the same.
Verify events are sent from Dfns
Verify webhook signatures to confirm that received events are sent from Dfns. Dfns signs webhook events it sends to your endpoints by including a signature in each event’sX-DFNS-WEBHOOK-SIGNATURE
header. This allows you to verify that the events were sent by Dfns, not by a third party.
Dfns signatures is a HMAC of the received event payload, using SHA-256 hash function and the webhook secret as the secret. It has this shape:
Only listen to event types your integration requires
Configure your webhook endpoints to receive only the types of events required by your integration. Listening for extra events (or all events) puts undue strain on the server and we don’t recommend it.Handle duplicate events
Webhook endpoints might occasionally receive the same event more than once
Receive events with an HTTPS server
If you use an HTTPS URL for your webhook, we validate that the connection to your server is secure before sending your webhook data. For this to work, your server must be correctly configured to support HTTPS with a valid server certificate.Exempt webhook route from CSRF protection
If you’re using Rails, Django, or another web framework, your site might automatically check that every POST request contains a CSRF token. This is an important security feature that helps protect you and your users from cross-site request forgery attempts. However, this security measure might also prevent your site from processing legitimate events. If so, you might need to exempt the webhooks route from CSRF protection.Local Development
To add a new webhook, you first need a http server which can receive requests from public internet. During development, one way to achieve this (without deploying a new server on a cloud provider), is to spin up a local server on your machine (localhost), and then use a tunnel services (eg https://ngrok.com) to create a public url pointing to your local server. As an example, here are steps to create a basic Express server in NodeJS:- Create a new npm project, install express
- Add a new file
index.js
:
- In one terminal, run your server
- In another terminal, start a ngrok tunnel pointing to your local server
- Now, you can Create a Webhook using the url displayed in the result of above the terminal (looking like “
https://xxxxxx.ngrok-free.dev
”), and test that the webhook is setup properly by using Ping Webhook. If properly setup, you should see incoming events received by your local server.
If you use a free Ngrok account, every time you re-launch the tunnel you’ll get a new url, so make sure you update the Dfns webhook url to test.