What is a Webhook?
A webhook is an HTTP request sent by one system to notify another that an event occurred. Reliable implementations verify signatures, tolerate retries, and process duplicate deliveries idempotently.
How Webhooks work
A webhook producer serializes an event and sends it to a consumer-controlled HTTP endpoint, decoupling asynchronous state changes from polling. Delivery is normally at least once rather than exactly once, because a lost response leaves the sender unable to know whether processing succeeded. The receiver therefore authenticates the original request, records an event identity, acknowledges promptly, and moves expensive media or business work to a durable queue.
Key facts
- Providers define exactly what is signed: some sign the raw request bytes plus a timestamp, while Transloadit sends an
application/x-www-form-urlencodednotification whosesignaturefield holds a lowercase hexadecimal HMAC-SHA1 of the exacttransloaditfield string. Choose verification secrets from trusted server-side configuration for the expected Assembly and Workspace, because a replay can be signed with a different applicable key; the webhook verification contract has the full rules. Verify the payload the provider defines, never a reserialized version of it. - Returning a success response only after lengthy downstream work increases timeouts and retries; persisting the event before acknowledging allows processing to continue asynchronously.
- Retries can duplicate or reorder events, so the event identifier and current resource version are safer guards for side effects than assuming each endpoint call is unique.
When Webhooks matter
Webhooks can continue application logic when asynchronous media processing completes or fails. Consumers must authenticate requests and avoid repeating side effects when the sender retries an event.