Get your delivery software ©2017
This resource covers:
Ais a tool for retrieving and storing data from a certain event. They allow you to register an http:// or https:// URL where the event data can be stored in JSON formats. For Deliveryby apps, webhooks are commonly used for:
Think of it this way, if you have have to poll for a substantial amount of data, you should be using webhooks.
Webhooks can be registered for the following events:
You can set up your webhooks through your store admin.
The issue with testing your webhooks is that you need a public visible URL to handle them. Unlike client-side redirects, webhooks originate directly from the server. This means that youuse the following as an endpoint in your testing environment:
If you are developing an app for a particular shop, you can configure your webhooks through your shop admin. Go to the Advanced Settings > Webhooks page.
Select the event type you want to listen for from the drop-down box and enter the URL (http:// or https://) where you want to receive notifications.
After you have created at least one webhook, you will be presented with a secret that you can use to validate the integrity of these webhooks
If you want to capture the contents of a webhook to examine them, the easiest way is to set up a new subscription with a service like LocalTunnel, RequestBin or PostCatcher (described above) which will capture the result and let you view it in a browser.
RequestBin allows you to create an URL wich will collect any requests made to it. You can then inspect your requests and see the values returned. The URL provided is temporary and can only be used for 20 requests or for 48 hours (whichever comes first).
Once you register a webhook URL with Deliveryby, we will issue a HTTP POST request to the URL specified every time that event occurs. The request's POST parameters will contain JSON data relevant to the event that triggered the request.
Your webhook acknowledges that it received data with aresponse. Any response outside of the 200 range will let Deliveryby know that you did not receive your webhook. To this end, Deliveryby has implemented a 5-second timeout period and a retry period for subscriptions. We wait 5 seconds for a response to each request, and if there isn't one or we get an error, we retry the connection to a total of 19 times over the next 48 hours. A webhook will be deleted if there are 19 consecutive failures for the exact same webhook.
You should monitor your admin for failing webhooks. If you're receiving a Deliveryby webhook, the most important thing to do is respond quickly. There have been several historical occurrences of apps that do some lengthy processing when they receive a webhook that triggers the timeout. This has led to situations where webhooks were removed from functioning apps.
To make sure that apps don't accidentally run over the timeout limit, we now recommend that apps defer processing until after the response has been sent.
Webhooks created through the API by a Deliveryby App can be verified by calculating a digital signature.
Each Webhook request includes aheader which is generated using the app's shared secret, along with the data sent in the request.
Webhooks created manually through the Deliveryby admin will need to be verified with the secret found within the webhooks section of the notifications area.
To verify that the request came from Deliveryby, compute the HMAC digest according to the following algorithm and compare it to the value in theheader. If they match, you can be sure that the Webhook was sent from Deliveryby and the data has not been compromised.
Below is a simple example in Ruby using the Sinatra web framework of how one might verify a webhook request.
And here's a PHP version: