Glossary · Technical

What is a webhook?

A webhook is an HTTP request that one system sends to a URL you control when a specific event happens — pushing data to you as it occurs, rather than making you repeatedly ask whether anything has changed.

[01] THE LONGER ANSWER/ TECHNICAL

Why webhook matters

The name is unhelpful and the idea is simple. Instead of your code polling an API every minute asking "anything new?", you give the other system a URL, and it makes a POST to that URL the moment there is something to say. That inversion is the entire concept. Everything else — signatures, retries, idempotency — is machinery for making it reliable, because an HTTP request from a stranger to a public URL is a considerably more dangerous thing than a request you made yourself.
[02] HOW IT WORKS/ IN PRACTICE

You register a URL and some events

You tell the sending system where to POST and which events you care about. Most systems let you subscribe to a subset, which is worth doing — an endpoint receiving everything and discarding most of it is a cost you pay on every event.

Each delivery is signed

A well-built webhook carries a signature: an HMAC over the request body and a timestamp, computed with a secret only you and the sender know. Verifying it is what distinguishes a webhook from a public write API that anybody can post to.

Failures are retried

If your endpoint returns a non-2xx or times out, the sender retries with a growing delay, then eventually gives up and marks the endpoint failing. This is why acknowledging fast and doing the work afterwards matters — a slow handler and a broken one look identical from the outside.

Retries mean duplicates

Because a delivery can succeed on your side and fail to be acknowledged, any retrying system delivers at least once, not exactly once. Handlers must be idempotent — keyed on the event id — or you will double-process.
[03] WHAT IT IS NOT/ CONFUSED WITH

Webhook against the terms it gets mixed up with

Most of the confusion in this category is vocabulary rather than substance. These are the terms webhook is most often used interchangeably with, and the difference that actually matters in each case.

An API

With an API, your code makes the request. With a webhook, theirs does. Most products have both, and they serve opposite directions of the same conversation.

Polling

Polling is asking repeatedly on a schedule, which is simple and wastes most of its requests. A webhook arrives when there is something to say. The trade is that polling fails visibly and webhooks fail silently.

WebSockets

A WebSocket is a connection held open in both directions for as long as both ends are up. A webhook is a single one-way HTTP request per event, with no connection to maintain — which is why it is the more common choice between two servers.

[04] WHERE IT MISLEADS/ THE CAVEAT

What a definition will not tell you

Two mistakes account for most broken webhook integrations, and both are avoidable in a line of code. The first is verifying the signature against parsed and re-serialised JSON rather than the raw body — parsing changes whitespace and key order, so the signature never matches and the bug looks like a server problem. The second is not rejecting old timestamps, which leaves a captured request replayable against you forever, signature and all.

What FishOut does about it

FishOut sends a signed POST when a mention arrives, is triaged, changes status or gets a draft — on every plan including Free. The payload carries the post’s relevance, labels, sentiment and Reply call. Every request carries an HMAC-SHA256 signature over the raw body with a timestamp, retries on failure, and marks the channel failing rather than retrying indefinitely.

Questions