Menu
Webhooks are a powerful yet amazingly simple way to connect two different applications together. When a change happens in one system, that sending system sends a call to a webhook that is set up in the receiving system.
It’s like a modern food delivery system. Notifications are sent out instantly as the order goes through each stage of production and delivery. Compare that to phoning periodically to find out the status of an order.
Without Webhooks, the standard way to get updates from one system to another is by repeatedly calling the secondary system and looking for changes. This is commonly done by keeping track of the timestamp of the last change or the value of the last record ID.
This is the phoning approach.
The disadvantages of this method:
Webhooks are a two-way communication method. Both the sending and receiving must support webhooks for the process to work.
The sending system is normally pre-configured with a set of webhook events that can be paired with any receiving system. The sending system sends its message as a one-time JSON payload. The receiving system sits and waits for messages to arrive. It is up to the receiving system to process these messages.
{
“id”: “evt_1M6zLLKYwoinuLywAA49jRa2”,
“object”: “event”,
“api_version”: “2020-08-27”,
“created”: 1669134547,
“data”: {
“object”: {
…
quantity: 3
…
}}}
There is no other communication that occurs other than the receiving system responding with “Ok” when it receives a valid message. The benefits of webhooks are clear:
In the example above, Stripe makes a webhook call when there is a change made to a customer’s subscription. The quantity value, which is what we are interested in, is shown highlighted in the JSON.
Setting up a webhook from a sending system is normally quite easy. Stripe is no exception. The Ruly webhook endpoint is entered, and then the events that should be sent to the webhook are selected from the list.
A separate webhook is normally required for each event. Here Stripe is sending several events, but they are all for the same customer.subscription object and the JSON can be processed with a single webhook rule.
Creating a webhook in Ruly is just as easy. Webhooks are created as a type of Rule. Give your webhook a name and Ruly generates an endpoint automatically which is ready to go to start accepting requests.
Note the API Key field. You can get this key or secret value from the originating system.
Now that we have a working webhook we need to do something with the results of these calls. For now, we can view what was sent by looking at the Logs tab for the webhook.
Here we can see the full header and body of the webhook call.
To process the data from the call, add a Create Operation to the webhook. This will create (or update) a subscription record with the new quantity. Note how fields are mapped from JSON using the “.” symbol to identify where in the hierarchy, the key/value pair appears.
With the create operation now running, when the webhook is called, the data is saved into a data table.
We need to secure the webhook so that it won’t process calls made to it unless we have some assurance that the call is coming from the intended source. There is no traditional authentication or token used with a webhook call, so alternate means are used.
The body of the request is hashed using a customer secret, and that hash value is passed with the call to the webhook. When the message is received, Ruly applies the same hashing formula and compares the hash value with the one provided in the request to verify that the message is genuine.
In the webhook setup, Ruly provides a way to configure how the security check hashing is applied, so it can be adapted to different providers.
Ruly’s configurable tools make it easy to create, process, and secure webhooks without using code and integrate these into applications built on the Ruly platform.
If you have any comments or questions, you can reach me at stan.marsden@rulyapp.com.