Skip to content
Latchkey

What Is a Webhook? Event-Driven HTTP Callbacks

A webhook is a user-defined HTTP callback: when something happens, a service sends an HTTP request to a URL you registered, pushing the event to you instead of making you poll.

Polling an API repeatedly to ask "anything new yet" is wasteful. Webhooks invert that: you give a service a URL, and it posts to that URL the moment an event occurs. Pushes, merges, and releases trigger CI through webhooks, making them the backbone of event-driven pipelines.

Push, not poll

You register an endpoint with a provider. When the matching event happens, the provider sends an HTTP POST with a payload describing it. Your service reacts immediately rather than discovering the change on its next poll.

What triggers CI webhooks

  • A push to a branch.
  • A pull request opened or updated.
  • A tag or release created.
  • A deployment status change.

Verifying authenticity

Because anyone could POST to your URL, providers sign payloads with a shared secret. The receiver verifies the signature before trusting the request, which prevents spoofed events from triggering pipelines.

Delivery is best-effort

Webhooks can be missed if your endpoint is briefly down or slow. Good providers retry failed deliveries and expose a log of attempts so you can replay events that did not land.

Webhooks in CI/CD

The event that starts a pipeline is usually a webhook from your source host. Deploys also send webhooks outward, for example to notify a chat channel or update a status page when a release completes.

Transient delivery failures

A receiver returning a 5xx during a momentary blip causes the provider to retry later, so a brief outage rarely loses events. Latchkey runner endpoints tolerate transient blips and rely on provider retries so a single failed delivery does not silently drop a build trigger.

Key takeaways

  • A webhook is an HTTP callback that pushes events instead of being polled.
  • Payloads are signed so receivers can verify they are genuine.
  • Delivery is best-effort with retries, so design receivers to be idempotent.

Related guides

Tired of flaky CI? Latchkey auto-heals failed jobs and retries them for you. Start free →