Glossary Term

Webhook

glossary webhook featured

A webhook is an automated HTTP request that one application sends to another the moment a specific event happens. Instead of your system asking for new data, the source system pushes the event data to a URL you provide. Webhooks connect payment processors, form tools, CRMs, and ad platforms so that one event can trigger an action in another app within seconds.

Developer Jeff Lindsay coined the term in a 2007 blog post, borrowing “hook” from the programming idea of a user-defined callback.

How a Webhook Works

A webhook works in four steps:

  1. You register a webhook URL (the endpoint) with the source app and choose which events to receive.
  2. An event occurs, such as a completed payment or a new form submission.
  3. The source app sends an HTTP POST request to your endpoint with a JSON payload describing the event.
  4. Your server returns a 2xx status code to confirm receipt, then processes the data.

A typical HTTP webhook delivery looks like this:

POST /webhooks/orders HTTP/1.1
Host: shop.example.com
Content-Type: application/json
X-Hub-Signature-256: sha256=5257a869e7ecebeda32affa62cdca3fa51cad7e77a0e56ff536d0ce8e108d8bd

{"id": "evt_1042", "type": "order.paid", "created": 1793174400, "data": {"order_id": 88231, "total": 129.00, "currency": "USD"}}

The type field tells your handler what happened. The id field lets you detect duplicate deliveries.

Webhook vs API

A webhook pushes data when something changes. An API waits for you to ask. With a standard API, your code polls on a schedule (“any new orders?”) and most requests come back empty. With a webhook, the provider calls you once per event, so data arrives in near real time and no requests are wasted.

The two usually work together. Many providers describe webhooks as part of their API, which is why people search for “webhook API”. A common pattern is to receive a small webhook, then call the API for the full record. A URL shortener API, for example, returns link and click data when you request it. linkutm’s REST API works this way: you pull click events on your own schedule rather than receiving pushed notifications.

Use polling when you need data in batches, or when the provider offers no webhooks. Use webhooks when an action must follow an event within seconds.

How to Secure a Webhook

Secure a webhook by verifying that every request comes from the expected sender. A webhook URL is a public endpoint, so anyone who finds it can send fake events.

  • Verify the signature: Stripe, GitHub, and Shopify all sign payloads with HMAC SHA-256 using a shared secret. GitHub sends the signature in the X-Hub-Signature-256 header. Stripe uses Stripe-Signature.
  • Check the timestamp: Stripe’s libraries reject events older than 5 minutes by default. This blocks replay attacks.
  • Use HTTPS only: Stripe requires HTTPS endpoints in live mode, with TLS 1.2 or higher.
  • Use the raw body: compute the signature on the unparsed request body. Stripe notes that any framework change to the raw body makes verification fail.
  • Keep secrets out of the URL: GitHub advises against putting API keys or credentials in the payload URL.

Webhook Delivery Rules and Best Practices

Respond fast and expect duplicates. Each provider sets its own delivery rules:

Provider Response deadline Retries on failure
GitHub 2xx within 10 seconds No automatic redelivery; redeliver missed events manually
Shopify 5 seconds Up to 8 times over 4 hours, then the subscription is removed
Stripe “Quickly” (no fixed number) Up to 3 days with exponential backoff in live mode

Build every webhook integration around these rules:

  • Acknowledge first, process later. Return 200 immediately and push the work to a queue.
  • Make handlers idempotent. Log processed event IDs and skip repeats. Stripe states endpoints “might occasionally receive the same event more than once”.
  • Do not rely on order. Stripe does not guarantee events arrive in the order they were created.
  • Subscribe only to events you use. Extra event types add load without adding value.
  • Monitor failures. A silent endpoint outage on Shopify ends with a deleted subscription.

Webhooks in Marketing

Marketing teams use webhook integrations to move events between tools without manual exports. Common examples:

  • A form tool sends each new lead to a CRM the moment it is submitted.
  • A payment processor sends a purchase event to a server, which forwards it to GA4 through the Measurement Protocol.
  • An email platform sends unsubscribe events to an ad platform to update suppression audiences.
  • Automation tools such as Zapier and Make start workflows from an incoming webhook URL.

Frequently Asked Questions

What is a webhook in simple terms?

A webhook is an automatic message one app sends to another when something happens. Think of it as a notification sent to a URL instead of a phone. The message carries data about the event, such as an order total or a new contact’s email. The receiving app then acts on it without anyone checking manually.

What is the difference between a webhook and an API?

An API responds when you send it a request, while a webhook sends you a request when an event occurs. APIs suit on-demand lookups and bulk data pulls. Webhooks suit real-time reactions to events. Most integrations use both: the webhook signals the change and the API fetches the details.

Is a webhook a POST request?

Yes, almost every webhook is an HTTP POST request with a JSON body. The sender posts the event payload to your endpoint URL. A few older services send form-encoded data instead of JSON. Your endpoint must accept POST and return a 2xx code to mark the delivery successful.

What is a webhook URL?

A webhook URL is the endpoint on your server, or in an automation tool, that receives webhook requests. You paste it into the sending app’s settings when you subscribe to events. It must be publicly reachable, and most providers require HTTPS. Treat it as sensitive, and verify signatures, because anyone with the URL can send it data.

Are webhooks secure?

Webhooks are secure when the receiver verifies each request. Unverified endpoints accept forged events, which can trigger fake orders or account changes. Check the HMAC signature, reject stale timestamps, and accept traffic over HTTPS only. Rotate the signing secret if you suspect it has leaked.

To see how pull-based link and click data compares with pushed events, read how a URL shortener API works.

Back to Glossary