What Is a Webhook and How Does It Work?
Learn what a webhook is, how it differs from polling, how signature verification and retries work, and how to build a secure webhook handler.
Expected Interview Answer
A webhook is a user-defined HTTP callback: instead of a client repeatedly polling a server for updates, the server itself sends an HTTP POST to a URL you registered the instant an event happens.
You register a target URL with a provider (say, a payment processor) for a specific event type, such as payment.succeeded. When that event occurs, the provider's system builds a payload describing it and issues an HTTP POST to your URL in near real time, eliminating the need to poll an API on a schedule. Because webhook delivery happens over an unreliable network, providers sign each payload (typically HMAC in a header) so you can verify authenticity, retry with exponential backoff on failure, and expect your endpoint to respond quickly with a 2xx status and do slow processing asynchronously afterward. Well-designed webhook consumers are idempotent, since providers may retry and deliver the same event more than once.
- Real-time updates without wasteful polling
- Reduces API load compared to constant polling
- Decouples the event producer from consumers
- Scales to many subscribers via fan-out delivery
- Signature verification secures the callback
AI Mentor Explanation
A webhook is like a stadium sending a push alert to a fan's phone the instant a wicket falls, instead of the fan repeatedly refreshing the scorecard app every few seconds. The stadium's system posts the event straight to the fan's registered device, signs it so the fan trusts it is genuine, and resends the alert if the first attempt fails to land, all without the fan lifting a finger to check.
Step-by-Step Explanation
Step 1
Register a callback URL
The consumer registers an HTTPS endpoint with the provider for one or more event types they care about.
Step 2
Provider detects the event
When the subscribed event occurs internally, the provider builds a payload describing what happened.
Step 3
Sign and POST the payload
The provider signs the payload (commonly HMAC-SHA256 in a header) and sends an HTTP POST to the registered URL.
Step 4
Consumer verifies and acknowledges
The endpoint verifies the signature, responds quickly with a 2xx status, and defers slow work to an async queue.
Step 5
Handle retries idempotently
If delivery fails or times out, the provider retries with backoff, so the consumer must dedupe by event ID.
What Interviewer Expects
- Contrasts webhooks (push) with polling (pull) and explains the trade-off
- Mentions payload signing for authenticity verification
- Explains retry behavior and the need for idempotent processing
- Knows the consumer should respond fast and process asynchronously
- Considers webhook security: HTTPS, signature checks, replay protection
Common Mistakes
- Doing slow processing synchronously inside the webhook handler
- Not verifying the payload signature, trusting any POST to the URL
- Assuming each event arrives exactly once instead of handling duplicates
- Confusing webhooks with a general publish-subscribe message queue
Best Answer (HR Friendly)
“A webhook is a way for one system to instantly tell another system 'something happened' by sending it a message the moment an event occurs, instead of that system having to keep asking 'did anything happen yet?' It's how apps get real-time updates, like a payment confirmation, without constantly refreshing.”
Code Example
const crypto = require('crypto');
app.post('/webhooks/payments', express.raw({ type: 'application/json' }), (req, res) => {
const signature = req.headers['x-signature'];
const expected = crypto
.createHmac('sha256', process.env.WEBHOOK_SECRET)
.update(req.body)
.digest('hex');
if (signature !== expected) {
return res.status(401).send('Invalid signature');
}
const event = JSON.parse(req.body);
// Respond fast; do slow work asynchronously
queue.enqueue('process-payment-event', event);
res.status(200).send('ok');
});Follow-up Questions
- How do you prevent processing the same webhook event twice?
- How would you design a retry and backoff strategy for failed deliveries?
- How do you secure a webhook endpoint against spoofed requests?
- How would you replay missed webhook events after an outage?
- What is the difference between a webhook and a message queue?
MCQ Practice
1. How does a webhook differ from polling?
A webhook is a push notification triggered by an event, avoiding the wasted requests of periodic polling.
2. Why do providers sign webhook payloads?
Signing (e.g. HMAC) lets the receiving endpoint confirm the payload wasn't forged or tampered with in transit.
3. Why must webhook consumers be idempotent?
Network failures cause providers to retry delivery, so the same event can arrive twice and must be safely deduplicated.
Flash Cards
What is a webhook in one sentence? — A user-registered HTTP callback that a server calls automatically the instant a subscribed event occurs.
Why should a webhook handler respond quickly? — Providers expect a fast 2xx response and will retry or time out if processing takes too long synchronously.
How do you verify a webhook is genuine? — Check the signature (commonly HMAC) in the request header against a shared secret before trusting the payload.
What must a webhook consumer handle regarding delivery? — Duplicate deliveries from retries, requiring idempotent processing keyed by a unique event ID.