What Are Webhooks and How Do They Work?
Learn what webhooks are, how event delivery and retries work, and how to verify signatures and handle duplicates safely.
Expected Interview Answer
A webhook is a user-defined HTTP callback where one system sends an automated POST request to a URL you configure whenever a specific event happens, letting your application react to events in near real time without repeatedly polling for changes.
Instead of your application asking a third-party service “did anything change?” every few seconds through polling, you register a URL with that service, and it pushes an event payload, typically JSON describing what happened, to your endpoint the moment the event occurs, such as a payment succeeding or a file being uploaded. Your endpoint should respond quickly, usually within a few seconds, with a 2xx status to acknowledge receipt, and do any slow processing asynchronously afterward, because most providers will retry with backoff if they do not get a timely acknowledgment, which can cause duplicate deliveries. Because webhook endpoints are public URLs that accept arbitrary POST requests, they must verify authenticity, typically by checking a signature the provider sends in a header, computed as an HMAC of the raw request body using a shared secret, rather than trusting the payload at face value. Idempotency matters too: since retries can deliver the same event more than once, handlers should key off a unique event ID and ignore ones already processed.
- Eliminates the latency and wasted requests of constant polling
- Delivers events to your system in near real time as they happen
- Decouples the event source from the consumer via a simple HTTP contract
- Signature verification lets you trust the payload came from the real provider
AI Mentor Explanation
A webhook is like giving the stadium your phone number and asking them to text you the moment a wicket falls, instead of you calling the stadium every thirty seconds to ask for an update. The stadium only reaches out when the specific event you registered for actually happens, saving both sides from constant back-and-forth calls. If your phone is busy and you miss the text, the stadium retries after a bit, so you need a way to recognize a repeat text about the same wicket rather than logging it twice. That push-only-on-event, verify-and-deduplicate pattern is exactly how webhooks work.
Step-by-Step Explanation
Step 1
Register a callback URL
You configure a public HTTPS endpoint with the provider and choose which events to subscribe to.
Step 2
Event occurs on provider side
The provider detects the subscribed event and prepares a JSON payload describing it.
Step 3
Provider POSTs to your endpoint
The provider sends the payload with a signature header so you can verify authenticity.
Step 4
You verify, ack, and process
Verify the signature, respond 2xx quickly, then process asynchronously while deduping by event ID.
What Interviewer Expects
- Clear articulation of push (webhook) vs pull (polling) event delivery
- Understanding that endpoints must verify request signatures, not trust payloads blindly
- Awareness that providers retry on failure/timeout, requiring idempotent handling
- Knowledge that the handler should ack fast and process slow work asynchronously
Common Mistakes
- Not verifying the webhook signature, trusting any POST to the endpoint
- Doing slow synchronous work before responding, causing timeouts and duplicate retries
- Assuming webhook delivery is exactly-once instead of designing for at-least-once
- Forgetting to handle out-of-order event delivery for related events
Best Answer (HR Friendly)
“A webhook is a way for one service to tell your app the instant something happens, instead of your app constantly asking “did anything change yet?” You give the service a URL, and it sends your app a message the moment the event occurs, so I make sure that endpoint checks the message is genuinely from that service and can safely handle getting the same message more than once.”
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')
}
res.status(200).send('ok') // ack fast
const event = JSON.parse(req.body)
queueEventForProcessing(event) // process asynchronously, dedupe by event.id
})Follow-up Questions
- How do you make a webhook handler idempotent?
- Why should you respond quickly and process events asynchronously?
- How do you verify a webhook payload actually came from the claimed provider?
- What happens if your webhook endpoint is down when an event is sent?
MCQ Practice
1. What is a webhook?
Webhooks are provider-initiated HTTP requests sent to your endpoint when a subscribed event occurs.
2. Why should a webhook handler verify a signature header?
Since the endpoint is a public URL, signature verification prevents forged or tampered payloads.
3. Why must webhook handlers be idempotent?
Retries on timeout or failure mean the same event can be delivered more than once.
Flash Cards
What is a webhook? — A provider-initiated HTTP POST sent to your URL when a subscribed event occurs.
Webhook vs polling? — Webhook pushes events as they happen; polling repeatedly asks if anything changed.
How do you trust a webhook payload? — Verify a signature header computed via HMAC with a shared secret.
Why must handlers be idempotent? — Providers retry on timeout, which can deliver the same event more than once.