Short answer
A webhook is an HTTP request that one system sends to another when an event happens — for example, "an order was created." Instead of repeatedly asking for changes, the receiving system is told. Webhooks give fast, efficient change detection, but they can be delayed, repeated, or delivered out of order, so receivers must verify, store, deduplicate, and back them up with reconciliation.
A webhook is a notification sent over HTTP. When something happens in system A — an order is placed, a product changes — system A sends a POST request to a URL that system B registered in advance. System B learns about the change within seconds, without having to ask.
How webhooks work
- Subscribe. The integration registers a URL for a topic (for example, “order created”).
- Event occurs. The platform creates a payload describing the event.
- Deliver. The platform sends the payload to the URL, usually with headers identifying the topic, the delivery, and a signature.
- Acknowledge. The receiver returns a 2xx response to confirm receipt.
- Retry. If the receiver fails or times out, the platform retries for a limited period.
What integrations must handle
Webhooks are fast and efficient, but platform documentation describes behaviors your design must expect:
- Duplicates. The same event may be delivered more than once. Deduplicate by delivery ID and make processing idempotent.
- Ordering. Events may arrive out of order. Use timestamps or fetch current state.
- Timeouts. Platforms expect fast responses (Shopify: within five seconds). Store and acknowledge first; process later.
- Disabling. Repeated failures can disable or remove the subscription.
- Gaps. Webhooks are not a complete record. Pair them with scheduled reconciliation.
Verifying webhooks
Anyone can send a POST request to a public URL, so receivers must verify authenticity:
- HMAC signatures: the platform computes a keyed hash of the body with a shared secret; the receiver recomputes and compares in constant time. Verify on the raw body bytes.
- Secret headers: the platform sends a custom header value you configured.
- HTTPS only, plus rate limiting and payload size limits at the edge.
Webhooks vs. polling
Webhooks push changes; polling pulls them on a schedule. Webhooks are faster and cheaper; polling is more predictable. Reliable integrations often combine both. See webhooks vs. polling.
Summary
Webhooks are HTTP notifications sent when events occur. They make integrations responsive and efficient, but delivery can be duplicated, reordered, or interrupted. Verify every request, store before processing, deduplicate, and reconcile on a schedule. For a step-by-step implementation, see how to handle Shopify webhooks reliably.
Frequently asked questions
Are webhooks secure?
They can be. Platforms sign webhook requests — Shopify with an HMAC in X-Shopify-Hmac-Sha256, WooCommerce with X-WC-Webhook-Signature — or let you add secret headers, as BigCommerce does. Always verify before processing and only accept HTTPS.
What happens if my endpoint is down?
The platform retries for a limited time, then may disable or remove the subscription. Shopify retries up to eight times over four hours; WooCommerce disables a webhook after five consecutive failures. Reconciliation catches events missed during downtime.
Do webhooks contain the full data?
It depends on the platform. Shopify and WooCommerce typically send the resource; BigCommerce sends minimal data such as an ID. Even with full payloads, fetching current data before processing avoids acting on stale versions.
Sources and further reading
Platform-specific statements on this page were checked against these sources on . Vendor APIs change; confirm details in the current documentation before you build.
- [1] Shopify webhook best practices — Shopify
- [2] WooCommerce REST API — webhooks — WooCommerce
- [3] BigCommerce webhooks overview — BigCommerce
Related reading
- Guides How to Handle Shopify Webhooks Reliably Build a Shopify webhook receiver that never loses events — HMAC verification, the five-second rule, deduplication, ordering, retries, and subscription removal.
- Comparisons Webhooks vs. Polling: Choosing How Your Integration Detects Changes Compare webhooks and polling for detecting changes in integrations — latency, completeness, cost, infrastructure, and failure modes — and learn when to combine them.
- Concepts What Is Event-Driven Architecture in Integrations? How event-driven architecture applies to ecommerce-ERP integrations — events, producers, consumers, queues, outbox patterns — and the trade-offs it introduces.
- Concepts What Is Idempotency? What idempotency means, why it is essential for reliable integrations, which HTTP methods are idempotent, and the common ways to make create operations safe to retry.