Webhooks are a way for your application to notify other application of updates as they happen. Learn more by visiting our Webhooks Knowledgebase.
Webhooks facilitate inter-app communication, without forcing clients to have to continuously poll for data. Typically webhooks are implemented as HTTP requests with a JSON payload.
In this day and age, integrations have increasingly become the norm. It's hard to come by a standalone monolithic application that does everything. Most of the time, a company's stack will include internal systems that communicate, existing systems that were bought, and they all need to be able to communicate efficiently.
Imagine a company that developed an ordering service, and has a set of internal services that must be integrated with. One of the requirements is to push orders into these systems in real-time.
This is where webhooks shine. It starts with implementing a webhook that's sent as soon as an order is placed. This announces to the world that a new order was placed, and includes relevant order information in the webhook payload.
Subscribers of the webhooks, i.e the services being integrating with, will receive an HTTP request as soon as an order is placed. They can choose to store that data, or request additional information from the ordering API based on the payload.
If you already have an API, webhooks can be considered a "reverse API", where instead of having consumers pull data from your system, your system pushes data to other systems.
Think of this simple scenario. You have systems and other companies that work with yours have systems. You've launched the first version of your API, and it's actively being used. Pretty common these days, isn't it?
Webhooks are a natural progression of an integration layer. It's step two once you have a functional API. It gives consumers another integration option so real-time, instant integrations can be built with application data.
Companies like Stripe use webhooks to deliver notifications as part of their API. Operations like a subscription failing to renew, or a payout being initiated are included as webhooks. If these didn't exist, customers would have to continuously poll Stripe's API and list all subscriptions along with their status. Multiply a request every minute (or second!) by 2 million customers, and you've created a recipe for a technical disaster. With webhooks, Stripe delivers real-time notifications as soon as an operation completes. This allows consumers of Stripe's webhooks to request additional information and update customer records to reflect what's happening on Stripe.
Webhooks are the logical next step if a company has tirelessly invested in their API, and wants to encourage efficient, solid, real-time integrations. Companies like Trello, Stripe, and Hubspot are all examples of real-world business that offer webhook delivery as part of their integration options.
A webhook at its core is a simple HTTP request that hits a specific endpoint, and has a JSON payload. Sending a simple webhook using cURL would look something like this:
curl --location --request POST 'https://app.hooky.me/api/v1/webhook_events/trigger' \
--data-raw '{"event_name":"this.is.a.webhook","payload":{"my_key":"data goes here there everywhere"}}'
Usually, subscribers will respond with 200 OK to let the provider know that the webhook was received successfully.
Delayed deliveries are when webhook subscriber fails to respond in a timely manner. Typically, including a timeout on the request and failing after a certain interval is good practice. When sending potentially long-running webhooks, it's best to choose to send these in the background to avoid introducing delays in an application's user experience.
It's helpful to store event logs of when a webhook was sent, when a 200 response was received, and the actual payloads. If subscribers have a data issue, logs are there to refer back to and understand what's going on.
(without slowing down your application)
There are two things to consider when sending a large amount of webhooks.
When you consume webhooks, take the following into account:
We built Hooky to help simplify the implementation around webhooks. The goal is for providers to be able to "fire & forget", i.e make a request to a specific endpoint with a payload, and Hooky handles delivering the webhook, retrying it if it fails, and timing out if necessary - all while making sure your events are logged.
Most importantly, Hooky scales horizontally to tens of millions of webhooks, or thousands of webhook consumers.
Send your first 5000 webhooks, free. See sending scalable, reliable webhooks with Hooky for more information.
Webhooks are a logical extension of your API. It gives other applications an easy-to-use integration option that avoids unnecessarily polling on an API, and enables real-time integrations.
Delivering webhooks reliably can be challenge - the right architecture can make or break your integrations.