What is a Webhook?
Webhooks are automated messages sent from web pages or apps to notify when something happens.
The term was coined by Jeff Lindsay in 2007 from the computer programming term hook.
In web development, they add or alter the behavior of web pages or web applications with custom callbacks. Callbacks can, in turn, be maintained, modified, and managed by 3rd-party users and developers who are not part of the core development team of the application or page in use. They are usually written in JSON, and requests are done as HTTP POST requests.
How do webhooks work?
Events trigger webhooks, for example, when a new component is pushed to a repository or page.
When events occur, the source site makes an HTTP request to the URL configured for the webhook. Users can configure them to cause events on one site to invoke further actions. Habitual uses include building triggers for continuous integration systems and notify bug tracking systems.
Because they use HTTP, they can be easily integrated into web services without adding new infrastructure, making them widely used.
The request process
- Choose events: Select the events (or topics) on the platform you want notifications about.
- Register your endpoint: Provide the platform with a publicly accessible URL within your application. This is where it will send the webhook notifications.
- Start receiving: You’ll automatically receive webhook requests at your designated URL when a chosen event occurs.
Consuming a webhook
- Set up your endpoint: Ensure your application has a designated URL ready to handle incoming HTTP requests (regular web requests). Refer to the provider’s documentation for specific guidelines.
- Webhook payloads typically send data in JSON or XML formats.
- Confirm receipt: Send a 200 or 302 status code to the source application to acknowledge receipt.
- Handle duplicates: Design your system to handle possible duplicate requests gracefully (idempotency). This ensures that repeated webhooks don’t lead to unintended actions.
- Option to fan out: If applicable, you can configure your endpoint to distribute the received webhook to multiple destinations for broader use of the data.
Analogy: The subscription service
- You: An application waiting for updates
- Source application: The subscription box company
- Event: Your monthly subscription box is ready and shipped
- Webhook URL: Your address (where the notification/package arrives)
- Webhook trigger/notification: The company sends a tracking number and shipping confirmation to your address (via email, SMS, etc.).
- Your reaction: You excitedly check the tracking information and anticipate the box’s arrival.
Why use webhooks?
- No more polling: They eliminate the need for your app to check for updates, saving valuable resources constantly.
- Quick setup: Most webhook-enabled services offer easy configuration through their user interface. Simply provide your app’s webhook URL and choose the types of events you care about.
- Real-time updates: Get notified when an event happens, ensuring the fastest possible data transfer.
- Efficient communication: They are ideal for sending lightweight, event-driven notifications. They streamline communication by focusing on the essentials.
POST or GET
Depending on the provider, you might receive requests as GET or POST requests.
GET requests have their payload appended to the webhook URL as a query string.
POST requests have their payload in the request body, which might contain other properties, such as authentication tokens.
What is the difference between API and webhook?
Webhooks are a subset of the APIs, meaning they are more limited.
They automatically send data in response to a specific event without request from another software. On the other hand, APIs are more versatile and are manual.
What are webhooks used for?
They notify the occurrence of an event in one system to another. For example, you have subscribed to content that charges your card monthly. That service wants to send you a message each time it charges your credit card.
So, that service subscribes to banks’ service to send a webhook when charging a credit card to their emailing service. The bank’s service is the source, the triggered event is a credit card charge, and the destination is the streaming email service.
Webhooks for infrastructure automation
They simplify communication between applications and go further by automating Infrastructure-as-Code (IaC) and enabling GitOps practices.
Infrastructure as Code (IaC)
IaC means managing infrastructure using code (like any other software project). This means version control, modularity, and the potential for automated deployment.
GitOps
GitOps uses Git as the single source of truth for infrastructure and application configuration. Changes in the Git repository automatically trigger infrastructure updates.
They bridge the gap between your Git repository and automation tools:
- Event triggers: A code change in the repo fires a webhook.
- Notification & action: The webhook informs your automation engine, which can execute workflows to apply the changes.
Event-driven automation: Extend this concept by connecting webhooks to event monitoring tools. They can then trigger automated responses to issues (security alerts, service failures, etc.), creating a self-healing system.
