We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design and AI Engineering, by Roni Das. 984 interactive lessons.
Start LearningIntermediate · Messaging & Event Systems
An HTTP callback triggered by an event. Instead of polling for updates, the source system pushes a notification to your URL when something happens.
In short
A webhook is an HTTP request that one system sends to a URL you control the moment a specific event happens, so you get notified instantly instead of repeatedly asking "did anything change yet?". The source system pushes a small JSON payload to your endpoint; your server receives it like any other incoming HTTP POST and acts on it.
In short
A webhook is an HTTP request that one system sends to a URL you control the moment a specific event happens, so you get notified instantly instead of repeatedly asking "did anything change yet?". The source system pushes a small JSON payload to your endpoint; your server receives it like any other incoming HTTP POST and acts on it.
Learn it in the course
This page is the free part.
₹1,111 in India$25 everywhere elseonce, for the whole course
The System Design course covers Webhook across a run of lessons, not one page. These 4 alone are about 105 minutes of step-by-step reading, every one with a quiz.
Don't call us, we'll call you, server-to-server event notifications over HTTP.
HTTP callbacks for automated incident response, trigger workflows on alert.
Path-based routing for microservices request routing, tested on real nginx, Envoy and HAProxy: nginx location order, ALB path rules, Ingress, path vs host.
One-way server push over HTTP, real-time updates without the complexity of WebSockets.
all part of
System Design Masterclass
770 lessons · about 287 hours · 18 free to read
₹1,111in India, by UPI
$25everywhere else, by PayPal
It is really nice and good Please join the course
You own this course
Continue with Webhookspay once,
yours for life
A webhook is a reverse API call. With a normal API, your code calls someone else's server to ask for data. With a webhook, you flip the direction: you register a URL with the other system, and when an event you care about occurs, that system calls your URL.
The mechanics are plain HTTP. The source sends a POST request to your endpoint, usually with a JSON body describing the event, for example a payment that succeeded or a git push that landed. Your server reads the body, does whatever work the event requires, and returns a 200 status code to confirm receipt.
The word 'hook' means a place where you attach your own behavior. You are hooking your code into another system's event stream over the web, which is where the name comes from.
First you tell the provider where to send events. This is the subscription step: you give Stripe or GitHub a URL like https://yourapp.com/hooks/payments, and sometimes you also pick which event types you want.
When the event fires, the provider builds a payload and POSTs it to your URL. Most providers sign the request so you can verify it really came from them. Stripe puts an HMAC SHA-256 signature in a Stripe-Signature header; you recompute the signature using your shared secret and reject the request if it does not match. Skipping this check means anyone who knows your URL can forge events.
Your endpoint should reply fast, ideally under a few seconds, and do heavy work afterward. The common pattern is to write the payload to a queue or table, return 200 immediately, and process it in the background. If you return an error or time out, the provider retries, often with exponential backoff for hours. Those retries mean the same event can arrive twice, so you must handle them idempotently by tracking the event ID and ignoring duplicates.
Reach for webhooks when you need near real-time reactions to events that happen on someone else's system: a checkout completed, a CI build finished, a Slack message posted, a subscription renewed. They are far cheaper and faster than polling, because the provider does no work and your server does no work until something actually happens.
The cost is operational complexity on your side. Your endpoint must be publicly reachable, always up, fast, and secure. You have to verify signatures, deduplicate retries, and decide what to do when a webhook is missed entirely, since delivery is best-effort, not guaranteed. A good safety net is a periodic reconciliation job that pulls the full state from the provider's API to catch anything that slipped through.
Webhooks are also one-way and fire-and-forget from the sender's view. If you need a request and response in the same call, or guaranteed ordering and exactly-once delivery, a proper message queue or a streaming platform like Kafka is the better fit.
Say you run an online store and want to ship an order the instant payment clears. You register https://store.com/hooks/stripe with Stripe and subscribe to payment_intent.succeeded.
A customer pays. Stripe POSTs a JSON payload with the payment ID, amount, and customer details to your URL, along with a signature header. Your server verifies the signature, checks that it has not already processed that payment ID, enqueues a 'fulfill order' job, and returns 200 in under a second.
A background worker then picks up the job, marks the order paid, triggers the warehouse, and emails a receipt. The customer never waited for any of this, and your server never had to poll Stripe asking whether the payment went through.
Stripe
Sends webhooks for every payment lifecycle event and signs them with HMAC SHA-256 so you can verify authenticity before fulfilling orders.
GitHub
Fires webhooks on pushes, pull requests, and issues to trigger CI pipelines, deployments, and bots.
Slack
Incoming webhooks let apps post messages into channels, and event subscriptions push channel activity to your server.
Shopify
Notifies your app of orders, refunds, and inventory changes so external systems stay in sync without polling the Admin API.
Direction. With a normal API you call the provider to pull data on demand. With a webhook the provider calls you, pushing data the moment an event happens. Webhooks are event-driven and instant; API polling is request-driven and repeated.
Verify the signature the provider sends in a header by recomputing it with your shared secret, reject anything that does not match, serve the endpoint only over HTTPS, and treat the URL itself as a secret. Never act on a payload you have not verified.
Most providers retry failed deliveries with exponential backoff for minutes to hours, but delivery is best-effort, not guaranteed. To be safe, run a periodic reconciliation job that pulls current state from the provider's API and catches any events you missed.
Retries and network timeouts can cause the provider to resend an event it already delivered. Make processing idempotent: store each event's unique ID and skip any ID you have already handled, so duplicates have no effect.
Use a queue or streaming platform like Kafka when you need guaranteed delivery, strict ordering, or exactly-once processing inside your own systems. Webhooks are best for receiving best-effort, near real-time event notifications from third parties.
Pub/Sub
A messaging pattern where publishers send messages to topics, and subscribers receive messages from topics they care about. Publishers don't know who's listening.
HTTP
The protocol powering the web. A request-response model where clients ask for resources and servers respond. Stateless by design.
Asynchronous
A communication model where the caller fires off a request and continues without waiting for a response. Essential for non-blocking I/O and event-driven systems.
Message Queue
A buffer that stores messages between producers and consumers. Messages are processed one by one, in order. Think of it as a to-do list for your services.
Kafka
A distributed event streaming platform that handles millions of events per second. Used by LinkedIn, Netflix, and Uber for real-time data pipelines.
Kafka Topic
A named feed or category to which producers publish records. Topics are split into partitions for parallelism, and each partition is an ordered, immutable log.
This page explains the idea. The "Webhooks" lesson builds it up step by step, with diagrams. It is part of the System Design Masterclass course, which has 770 lessons. 18 of them are free to read. You pay once and keep it for life, with no subscription.
Open the Webhooks lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.
Asked about Webhook in an interview?
Each question has why it is asked, a full answer, what the interviewer listens for, the follow-ups, the common mistakes and a diagram (268 diagrams in all). A PDF you keep, junior to staff level.
India: UPI, cards or netbanking through Razorpay. Elsewhere: card or PayPal. Download at once from My packs.
