What is a webhook?

A webhook is a URL you give to a third-party service so it sends an HTTP request to your application as soon as an event happens on its side: a payment collected, a form submitted, an order shipped. It's the opposite of polling: instead of querying an API every five minutes to see if there's anything new, you wait to be told.

The official definition

GitHub's documentation puts it this way: "Webhooks let you subscribe to events happening in a software system and automatically receive a delivery of data to your server whenever those events occur." And it draws the comparison in the next sentence: webhooks are used to receive data as it happens, "as opposed to polling an API (calling an API intermittently) to see if data is available" (GitHub Docs, About webhooks).

The word therefore means two things at once: the mechanism, and the URL that receives it. In an integration conversation, "give me your webhook" means "give me the address where I should send the events".

What actually travels

A POST request, a JSON body, some headers. Nothing more exotic.

Stripe sums up well what a serious sender expects from you: a publicly accessible HTTPS URL, TLS 1.2 or 1.3 only, and a 3xx redirect response counted as a failed delivery (Stripe Docs, Receive Stripe events in your webhook endpoint).

The three rules people learn too late

Respond fast, think later. Your endpoint must return a 2xx code before any business logic that might take time. Stripe puts it unambiguously: you must return a 200 response before marking the invoice as paid in your accounting tool. Processing belongs in an asynchronous queue, not in the request.

Verify the signature. Without verification, anyone who knows your URL can send you a fake "payment succeeded" event and trigger a shipment. Stripe signs each event in the Stripe-Signature header with an HMAC SHA-256, timestamp included, and its libraries apply a default 5-minute tolerance between that timestamp and the current time — that's what blocks replay attacks. Careful: verification is done on the raw request body, and many frameworks modify it before your code sees it.

Expect duplicates and disorder. Stripe doesn't guarantee the delivery order of events and recommends tracking their identifiers rather than their timestamps to spot a duplicate. On failure, retries continue for up to three days with exponential back-off. Your processing must therefore be idempotent: receiving the same event twice must not charge twice.

And on the no-code side

The principle is the same, without writing a server. n8n's Webhook node accepts the DELETE, GET, HEAD, PATCH, POST and PUT methods, provides a test URL separate from the production URL, and can require basic, header-based or JWT authentication. The maximum payload is 16 MB, adjustable when self-hosting via the N8N_PAYLOAD_SIZE_MAX variable (n8n Docs, Webhook node).

One opinion to finish: turn on authentication from day one, even on a test workflow. An n8n webhook URL left open is a public entry point into your automations, and it always ends up in a ticket, an email or a screenshot.