Webhook
A webhook is an HTTP callback that is automatically triggered when a specific event occurs in a system. Unlike classic API polling, where a client regularly checks for updates, a webhook actively sends data to a defined URL – in real time, as soon as the event happens. Webhooks are the foundation for event-based architectures and Workflow Automation .
How do webhooks work?
The principle is simple: 1. A system (sender) registers a target URL with the receiver. 2. When a defined event occurs (e.g., new commit, payment completed), the sender sends an HTTP POST request to the URL. 3. The receiver processes the data and responds with a status code. Typical webhook events: Git push, Stripe payment, CMS content update, CI/CD pipeline status, form submission.
Webhooks vs. API polling
Polling: the client regularly checks for changes – inefficient, generates unnecessary traffic, delays the response. Webhooks: the server actively notifies on changes – efficient, near real-time, reduces server load. Webhooks are the preferred approach for event-driven architectures. Combined with message queues (Redis, RabbitMQ), processing is decoupled and fault-tolerant.
Webhook security
Webhooks receive data from external systems – they must be secured: validate HMAC signatures (the sender signs the payload with a shared secret). IP whitelisting where possible. Rate Limiting on webhook endpoints. Idempotent processing (the same message can be processed multiple times without side effects). Manage webhook secrets via Secret Management , never hardcode them.
Webhooks in web development
GitHub webhooks trigger CI/CD pipelines on every push. Stripe webhooks notify about payment status. Headless CMS systems trigger SSG rebuilds on content changes. Monitoring tools send alerts via webhook. Chatbots receive user messages via webhook. Server-Side Validation of incoming webhook data is mandatory to prevent manipulation.
How we use it
A push to the main branch triggers our CI/CD pipeline via GitHub webhook: Angular is built, prerendered and deployed via FTP. For Django backends, content updates trigger an SSG rebuild via webhook. Monitoring alerts are automatically forwarded to Slack. Every webhook receiver validates HMAC signatures with secrets from Secret Management and processes events idempotently – duplicate deliveries produce no side effects.