How Webhooks Actually Work

Webhooks sounded complicated to me mostly because the name makes them sound like some special kind of technology.

They are basically HTTP requests sent in the opposite direction.

Normally my application asks another service for something:

my app → external API

With a webhook, the external service tells my application that something happened:

external service → my endpoint

A payment provider might send a webhook when a subscription renews. An email service might send one when a message arrives. A deployment system might notify another service when a build finishes.

The useful part is that my application does not need to keep asking:

Has anything changed yet?

The external service sends the event when it happens.

A basic webhook endpoint therefore does three things: receive the event, verify that it really came from the expected service and process it.

That verification step is important. A public webhook URL is still a public URL, so I should not trust a request merely because its JSON says "payment_succeeded".

Most serious providers include a signature that my backend can validate using a secret known to both sides.

There is one more detail that initially surprised me: the same webhook can sometimes arrive more than once.

That means the handler should ideally be idempotent. Processing the same event twice should not charge someone twice, create duplicate records or otherwise break the system.

Once I understood those two ideas — verify the sender and safely handle duplicates — webhooks stopped feeling like infrastructure magic.

They are simply event notifications delivered over HTTP.