25 essential webhook terms every developer should know — clear definitions with links to in-depth guides.
A set of rules and protocols that allows software applications to communicate with each other. In the webhook context, APIs are the pull-based counterpart to webhooks — your application sends a request to fetch data, rather than receiving it automatically. APIs use request-response cycles while webhooks use event-driven push notifications.
The endpoint URL that a webhook provider sends HTTP POST requests to when an event occurs. You configure this URL in the provider's dashboard (e.g., Stripe webhook settings). The callback URL must be publicly accessible over HTTPS and respond with a 2xx status code to acknowledge receipt of the webhook.
A holding area for webhook events that have exhausted all retry attempts and still failed to be processed successfully. Instead of silently dropping the event (and losing data), the event is stored in the DLQ for manual investigation and eventual replay. Every production webhook system should have a DLQ to prevent silent data loss.
A single try to deliver a webhook event to your endpoint. The first delivery attempt happens immediately when the event occurs. If your endpoint returns a non-2xx response or times out, the provider schedules additional delivery attempts with increasing delays (exponential backoff). Most providers allow 3-10 delivery attempts before giving up.
The specific URL path on your server that receives webhook HTTP POST requests. For example, https://yourapp.com/webhooks/stripe. Endpoints should be dedicated routes that validate signatures, parse payloads, and respond quickly. A single application may have multiple endpoints for different webhook providers.
A specific occurrence in the source application that triggers a webhook delivery. Examples include a payment succeeding in Stripe (payment_intent.succeeded), a push to a GitHub repository, or an order being placed in Shopify. Each event generates a webhook payload containing the event data.
A string identifier that categorizes what happened in the source application. Providers use dot-notation naming conventions like customer.subscription.deleted (Stripe) or push (GitHub). You can usually filter which event types trigger webhook deliveries to your endpoint.
A retry strategy where the delay between consecutive retry attempts increases exponentially — for example, 1s, 2s, 4s, 8s, 16s. This prevents overwhelming a failing endpoint with rapid retries and gives the target system time to recover. Most webhook providers combine exponential backoff with jitter (random variation) to avoid thundering herd problems.
The pattern of forwarding a single incoming webhook event to multiple downstream destinations simultaneously. For example, when Stripe sends a payment webhook, you might fan it out to your order service, analytics pipeline, and Slack notification channel. Fan-out requires independent retry tracking for each destination to prevent one slow consumer from blocking others.
A cryptographic method used to verify webhook authenticity and integrity. The provider computes a hash of the request body using a shared secret key and includes it in a request header (e.g., X-Hub-Signature-256). The receiver recomputes the hash with the same secret and compares — if they match, the webhook is authentic and untampered.
The HTTP method used to deliver webhook payloads. Webhooks use POST (not GET) because they send data to your endpoint rather than requesting it. The payload is included in the request body, typically as JSON. Your endpoint should parse the body, process the event, and return a 2xx status code to acknowledge receipt.
The property that processing the same webhook event multiple times produces the same result as processing it once. This is critical because providers retry failed deliveries, causing duplicate events. Without idempotent handling, you risk double-charging customers, sending duplicate emails, or corrupting data. Implement idempotency by storing processed event IDs and checking before executing side effects.
A unique identifier (usually the event ID from the provider) used to detect and skip duplicate webhook deliveries. Store the idempotency key in your database before processing an event. On subsequent deliveries of the same event, check for the key and skip processing if it already exists. This is the primary mechanism for achieving idempotent webhook handling.
The entry point where incoming webhook HTTP requests arrive in your infrastructure. In Kubernetes, an Ingress resource routes external traffic to internal services. In the webhook context, ingress refers to the publicly accessible layer that accepts webhook traffic — including load balancers, API gateways, or dedicated webhook ingestion services like SDNBros.
Random variation added to retry delays to prevent multiple failed webhooks from retrying at exactly the same time (the "thundering herd" problem). Instead of retrying at exactly 1s, 2s, 4s, the delay becomes 1s + random(0-500ms), 2s + random(0-1s), etc. Jitter distributes retry traffic more evenly and reduces load spikes on recovering endpoints.
The data sent in the body of a webhook HTTP POST request. Payloads are typically JSON objects containing the event type, a timestamp, and the event-specific data (e.g., the full payment object for a Stripe charge event). Payload size varies by provider — most support up to 1-5 MB. Always parse payloads leniently to handle schema changes gracefully.
The service or application that sends webhook events. Stripe, GitHub, Shopify, and Slack are common webhook providers. Each provider has its own webhook configuration interface, payload format, signature scheme, and retry policy. Understanding your provider's specific behavior is essential for building reliable integrations.
Restricting the number of webhook requests your endpoint accepts within a given time window. Rate limiting protects your endpoint from being overwhelmed by burst traffic — whether from a legitimate spike in events or a misconfigured provider sending floods. Return HTTP 429 (Too Many Requests) when limits are exceeded, and the provider will retry later.
Re-sending a previously delivered webhook event to your endpoint. Replay is used to recover from processing failures, test endpoint changes, or backfill missed events. Some providers offer replay from their dashboard; webhook management tools like SDNBros provide one-click replay with the option to edit the payload before re-sending.
An automatic re-delivery of a webhook event after a failed delivery attempt. Retries happen when your endpoint returns a non-2xx status code, times out, or is unreachable. Providers typically use exponential backoff with a maximum number of attempts (e.g., 5 retries over 24 hours). Your endpoint must be idempotent to handle retries safely.
When a webhook provider changes the structure of their payload over time — adding new fields, removing deprecated ones, or changing data types. Schema drift can break webhook handlers that use strict parsing. Protect against it by ignoring unknown fields, providing defaults for optional fields, and never assuming a field's presence without checking.
The process of validating that a webhook request was sent by the expected provider and has not been tampered with in transit. The provider signs the payload with a shared secret (using HMAC-SHA256 or similar), and your endpoint recomputes and compares the signature. Without signature verification, anyone who discovers your endpoint URL can send fake webhooks.
A security vulnerability where an attacker tricks your server into making requests to internal resources. In the webhook context, SSRF can occur if your endpoint processes a URL from the webhook payload and fetches it without validation — an attacker could point it to internal services (e.g., http://169.254.169.254 for cloud metadata). Always validate and restrict outbound URLs.
An HTTP callback that automatically sends data from one application to another when a specific event occurs. Webhooks follow a push model — instead of your application polling an API for updates, the source application sends an HTTP POST request to your configured URL the moment something happens. Webhooks power real-time integrations for payments, CI/CD, e-commerce, and messaging.
A persistent, bidirectional communication protocol between a client and server. Unlike webhooks (which are one-way HTTP callbacks from server to server), WebSockets maintain an open connection for real-time two-way data flow — ideal for chat, live dashboards, and collaborative editing. Webhooks are better for server-to-server event notifications; WebSockets are better for client-server real-time communication.
Put these terms into practice — capture, inspect, and debug real webhooks with our free tools.
Open Webhook Tester Browse All GuidesRelated guides: What is a Webhook? · Webhook vs API · Webhook Security · Retry Strategies
More: Learning Center | Webhook Security Guide | Webhook Idempotency | All Features