In today’s highly connected online world, nothing can function optimally in isolation. Achieving a task (almost) always involves the participation of more than one entity. E-commerce apps need to communicate with payment systems, payment systems need to communicate with banking systems, banking systems need to communicate with customer accounts…do you see the pattern?
The ability of independent online systems to communicate with one another and share data is the core of what makes online services valuable today. In this post, we will look at webhooks. A webhook is one of the many ways to facilitate communication between online services and by the end of this post, you will fully understand what webhooks are, how they work, and when to use them.
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.
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.
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.
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.
Now that you have registered for webhook requests, you have to be prepared to receive them.
Guide on implementing idempotency to prevent taking action on the same webhook multiple times, ensuring data integrity.
Learn what causes data integrity issues when working with webhooks and what are the preventive, and corrective strategies to solve them.
Learn how to use Hookdeck to fan out webhooks to different services.
You might get webhooks requests as GET or POST requests, dependent on the webhooks provider. GET webhook requests are simple and have their payload appended to the webhook URL as a query string. POST webhook requests have their payload in the request body and might also contain properties like authentication tokens.
Information rules the web, and getting information in real-time makes online services highly efficient and responsive to customer needs. Webhooks offers a non-complex way to make sharing information in real-time amongst online platforms possible.