What is a webhook? Push notifications between applications
A webhook is an automated message sent from one application to another when a specific event happens — instead of you repeatedly asking “has anything changed?”, the source system pushes a notification to a URL you provide the moment it does. A payment gateway confirming a transaction, a code repository reporting a new commit, a chat tool relaying an alert — all commonly arrive as webhooks. This guide covers the push-versus-pull distinction that makes webhooks useful, how the mechanism actually works, common uses, the practical concerns around securing and handling them, and how they fit into event-driven cloud architecture.
The idea: push, not pull
Our explainer on what an API is covers the typical request-response pattern, where your application asks a question and the other system answers — that is “pull”: you keep asking, on your own schedule, whether anything new has happened. Polling an API every few seconds to check for an update is simple to build but wasteful — most checks find nothing has changed — and it introduces delay, since you only find out on your next scheduled check.
A webhook flips that around. It is “push”: the source system calls you the instant the event happens, so there is no polling, no wasted checks, and effectively no delay. The trade-off is that you have to be ready to receive that call, which is a meaningfully different design than simply asking questions when it suits you.
How webhooks work
The mechanism itself is simple. You register a callback URL with the source system — an endpoint on your own application, publicly reachable, that you have built to receive the notification. When the event you subscribed to occurs, the source system sends an HTTP POST request to that URL, carrying a payload (typically JSON) describing what happened. Your endpoint receives the request, processes the payload, and normally responds quickly to confirm receipt.
Nothing about a webhook requires special protocols beyond ordinary HTTP — which is exactly why it has become such a common way for otherwise unrelated systems to integrate: any application that can receive an HTTP request can receive a webhook.
Common uses
Webhooks show up wherever one system needs to tell another that something has happened, without either side needing deep integration:
- Payment notifications — a payment provider confirming a transaction succeeded, failed or was refunded.
- CI/CD triggers — a code repository notifying a build system that new code was pushed, kicking off a pipeline.
- Chat and alerting — monitoring tools posting an alert directly into a team chat channel.
- SaaS-to-SaaS integrations — connecting tools that were never built to know about each other, by having one push events the other consumes.
The practical concerns
Because a webhook endpoint is a public URL that accepts incoming requests, anyone who finds it could, in principle, send it fake data — so verifying the sender matters. Most webhook providers sign each request with a secret known to both sides, and a well-built receiver checks that signature before trusting the payload, rather than assuming every request that arrives is genuine.
The other practical realities are handling retries and duplicates gracefully — a source system that doesn’t get a timely acknowledgement will often resend the same event, so a receiver needs to cope with processing the same notification twice without ill effect — and simply having an endpoint that is publicly reachable in the first place, which is a genuine constraint during local development.
How webhooks fit event-driven cloud architecture
Webhooks are one practical form of a broader idea: event-driven architecture, where systems react to things happening rather than constantly asking each other for status. Our explainer on message queues covers the other common mechanism for this — a queue that holds events for a consumer to process at its own pace, which suits high volumes and internal systems better than a webhook’s direct, immediate HTTP call. The two are complementary: a webhook is often the trigger, and the receiving system may drop the event onto a queue for reliable processing behind the scenes.
Where webhooks appear in developer certification study
Webhooks are core to the integration patterns tested on developer-focused exams. The AWS Developer Associate (DVA-C02) exam expects you to reason about event-driven integration between services, including where an HTTP callback fits versus a managed messaging service. The AWS Solutions Architect Associate (SAA-C03) exam tests the same reasoning at an architectural level — when a direct push integration is the right choice. Even the AWS Cloud Practitioner (CLF-C02) exam expects a basic, conceptual grasp of how cloud services notify one another of events.
Original practice questions, timed mock exams and revision notes. No card, nothing to pay.