Introduction
What is a webhook?
A webhook is an HTTP request, triggered by an event in a source system and sent to a destination system, often with a payload of data. Webhooks are automated, in other words they are automatically sent out when their event is fired in the source system.
This provides a way for one system (the source) to "speak" (HTTP request) to another system (the destination) when an event occurs, and share information (request payload) about the event that occurred.
What are webhooks used for?
Based on the definition above, I am sure you're already getting an idea of what webhooks are used for. Simply put, webhooks are used to communicate the occurrence of an event in one system to another system, and they often share data about the event. However, an example is always easier to illustrate so let's look at a case of webhooks in action.
Let's say you subscribe to a streaming service. The streaming service wants to send you an email at the beginning of each month when it charges your credit card.
The streaming service can subscribe to the banking service (the source) to send a webhook when a credit card is charged (event trigger) to their emailing service (the destination). When the event is processed, it will send you a notification each time your card is charged.
The banking system webhooks will include information about the charge (event data), which the emailing service uses to construct a suitable message for you, the customer.
How webhooks work
Webhook request process
For a system to send webhooks, the system has to be able to support the process. You can build your system to send webhooks by triggering HTTP requests for different types of events.
Webhooks are most common in SaaS platforms like GitHub, Shopify, Stripe, Twilio, and Slack because they support different types of events based on the activities that happen within them.
To receive webhook requests, you have to register for one or more of the events (also known as topics) for which the platform offers a webhook. A webhook request will be sent to a destination endpoint (URL). It can be your application, register the URL as the Webhook URL for that event.
Once the webhook registration for an event is complete, you will receive webhook requests at the destination URL you provided each time the event occurs.
Consuming a webhook
Now that you have registered for webhook requests, you have to be prepared to receive them.
Webhooks are regular HTTP requests and should be handled as such. (webhook providers always have documentation for implementation details.) Webhooks payloads are in serialized form-encoded JSON or XML formats. Webhooks are a one-way communication system but it is best practice to return a 200 or 302 status code to let the source application know that you have received it. It is also advised to make the webhook request operation at your end idempotent, as some source applications can send the same webhook request more than once. In this type of scenario, you want to ensure that your response to a webhook request is not duplicated as this might lead to a compromised system. A single webhook request can also be distributed to multiple destinations that require the information, in a process known as fanning out. This allows source systems to speak to more applications and better distribute information across the web.