Skip to main content

Command Palette

Search for a command to run...

What Is a Webhook? And Why Do They Exist?

Updated
3 min readView as Markdown
What Is a Webhook? And Why Do They Exist?
M
I'm a software engineer with over 15 years of experience. While my background is primarily in backend engineering, my work today spans cloud infrastructure, AI integrations, and the systems that support modern software applications. I started this blog to share what I’ve learned in a simplified, approachable way — and to add value for fellow developers. Though I’m an introvert, I’ve chosen to put myself out there to encourage more women to explore and thrive in tech. I believe that by sharing what we know, we learn twice as much — that’s precisely why I’m here.

You've probably heard the term webhook in engineering conversations and assumed it was something complicated.

It isn't.

A webhook is simply an HTTP endpoint on your server that another system calls to notify you when something happens.

A simple way to think about it is as a phone number.

Imagine you give someone your phone number.

Whenever they have something to tell you, they call you.

A webhook works the same way.

Phone number      → Webhook URL
Phone call        → HTTP POST request
Caller ID         → Signature verification
"Got it."         → HTTP 200 OK

When an Event Happens

Suppose you're integrating with a payment provider.

When a payment succeeds, they send an HTTP POST request to your webhook endpoint.

Your application receives the request, processes it, and returns 200 OK.

A simplified flow looks like this:

Payment succeeds
        │
        ▼
 Payment Provider
        │
 POST /webhook
        │
        ▼
 Your Application
        │
 Process event
        │
 Return 200 OK

Setting Up a Webhook

Before any events start flowing, there's usually a one-time setup.

First, you expose an HTTP endpoint in your application that will receive incoming events.

For example:

POST /webhook

You then provide that URL to the other system so it knows where to send events.

The sender also gives you a shared secret.

Your application uses that secret to verify that incoming requests really came from them before processing the event.

A typical webhook handler follows this flow:

Webhook arrives
        │
        ▼
Verify signature
        │
        ▼
Queue or store the work
        │
        ▼
Return 200 OK
        │
        ▼
Background worker

Notice that the handler itself stays lightweight.

Its responsibility is to acknowledge the event quickly. Any heavier processing—sending emails, updating databases, or calling other services—can happen afterward in a background worker.

Why Use Webhooks?

Without webhooks, your application has to keep asking another system if anything has changed.

This is commonly called polling.

With webhooks, the opposite happens.

The other system notifies you only when there's something new to report.

Here's a quick comparison:

Polling Webhook
Who starts the conversation? Your application The other system
When do you get updates? On your schedule When an event happens
Technology HTTP HTTP

Wrapping Up

A webhook is simply an HTTP endpoint on your server that another system calls to notify you when something happens.

The technology underneath is the same HTTP you've probably been using for years.

The only thing that changes is who starts the conversation.