Webhook Best Practices
Some things to note when working with Webhooks
Webhook URL
- If using
.htaccess
, remember to add the trailing/
to the URL you set. - Do a test post to your URL and ensure you can access the POST body.
- Ensure your webhook URL is publicly available (localhost URLs cannot receive events)
Always Verify Webhook Information
As a rule of thumb, always verify webhook notification information before taking action. Whenever you receive a webhook notification, before giving the customer value, you should call our API again to verify the received details and ensure that the data has not been compromised.
For instance, when you receive a successful incoming transaction notification, you can use our transaction endpoint to verify the transaction status before crediting the user.
This additional step helps guarantee the accuracy and security of the received data. Essentially, it will help protect your customers and your business from fraudulent activities.
Respond Early
For best practices, ensure your webhook endpoint respond within 60-90 seconds, or we will consider it a failure and retry the request.
Bitpowr may time out while waiting for a response if your application is likely to start a long-running task in response to the even; in this case, the event will be considered unacknowledged and queued to be resent later. You can avoid webhook duplication by having your application respond with a 200 right away before continuing the task.
Use Idempotency Scheme
When working with webhook events that involve transactions, it's best to handle the events in such a way as to avoid duplication. You can do this by making your webhook processing idempotent, ensuring that multiple webhook events give the same effect.
There's a possibility that, in some cases, we might send the same webhooks multiple times, and making the process idempotent would ensure that you don't give a customer value multiple times.
For every transaction webhook we send, there's always an idempotencyKey
value attached to the webhook payload. You can use this value as a unique field on your database.
Another way is to record the events and check for their status. If the events have not changed, you can ignore the request.
Updated 10 months ago