Ecommerce webhooks are automated HTTP callbacks your store fires the instant something happens.For example when someone places an order when a payment is made or when stock levels change these messages get sent away.
When someone places an order, a payment clears, stock changes, and downstream systems update right away instead of polling on a timer. To use them for order and stock sync, you register an endpoint URL with your platform, subscribe to the events you actually care about (say order.created or inventory.updated), verify each incoming request with a signature, return a fast 2xx response, and process the payload on a background queue.
If you do it correctly ecommerce webhooks help keep your ERP, warehouse, accounting, and marketplace inventory consistent within seconds, and they kill off the overselling and stale-data problems that polling drags in. Here is the thing that most people do not understand: the hard part is not sending the ecommerce webhook it is getting the ecommerce webhook in a way that’s reliable, safe and consistent.
What ecommerce webhooks actually are
A webhook is a “reverse API call.” With a normal API, your code asks the server for data. With a webhook the server will let you know when something new happens by sending an HTTP POST to a website address that you are in control of.
In ecommerce, the events that matter most are order lifecycle changes (created, paid, fulfilled, cancelled, refunded) and inventory changes (stock decremented, restocked, threshold crossed). Instead of your warehouse system constantly asking the store if there are any new orders every minute the store will send the order to the warehouse as soon as it is made.
That distinction is the whole reason webhooks exist. Polling is wasteful and slow. You either poll too often, burning rate limits and compute, or too rarely and introduce lag. Webhooks change this by sending updates soon as something happens so you get the information you need right away. For a deeper architectural framing of event-driven integration, the Wikipedia overview of webhooks is a clear, vendor-neutral starting point.
Webhooks vs polling vs API calls
It helps to see the three integration styles side by side before you commit. Each has a place. Webhooks win specifically for real-time, event-shaped data.
| Approach | How it works | Latency | Best for | Main drawback |
|---|---|---|---|---|
| Webhooks | Store pushes event to your URL | Seconds | Order & stock sync, payment confirmation | You must run a reliable receiver |
| Polling (scheduled API) | You query the API on a timer | Minutes (your interval) | Batch reports, low-urgency reconciliation | Wasteful, laggy, rate-limit pressure |
| On-demand API | You query when a user acts | Instant for that request | Reading current state in a UI | Doesn’t notify you of background changes |
In practice most mature integrations run webhooks and a periodic reconciliation poll as a safety net. Webhooks handle the real-time path; a nightly or hourly reconciliation catches anything a missed or out-of-order delivery left inconsistent. Treat the two as complementary, not competing.
The core events for order and stock sync
You rarely need every event a platform emits. For order and inventory synchronization, subscribe narrowly. It keeps your receiver simple and your logs readable .
Order events
order.created, new order placed; trigger fulfillment and reserve stock.order.paid/payment.succeeded, funds captured; safe to release goods and post revenue to accounting.order.fulfilled/order.shipped, push tracking to the customer and the marketplace.order.cancelled/order.refunded, restock items and reverse the accounting entry.
Inventory events
inventory.updated, quantity changed for a SKU/variant; propagate to every sales channel.inventory.low_stock, threshold crossed; trigger reorder or hide the listing.product.updated, price or status change that should mirror to connected channels.
For multi-vendor marketplaces the stock case is the sharp one. The same SKU may be sellable on your storefront, a vendor’s own site, and an external channel all at once. A single inventory.updated webhook that fans out to every channel is what stops you from selling the last unit twice. If you’re wiring inventory into a back-office system, our companion guide on how to connect your store to an ERP or accounting system covers the downstream mapping in detail.
How to set up an ecommerce webhook (step by step)
The mechanics are consistent across platforms. Here’s the sequence we recommend.
1. Build and expose a receiver endpoint
- Create an HTTPS endpoint, for example
POST https://api.yourstore.com/hooks/orders, that accepts JSON. It has to be publicly reachable and serve a valid TLS certificate; most platforms flat-out refuse to deliver to plain HTTP. During development, a tunneling tool can expose your local server so you can test against real deliveries.
2. Register the URL and subscribe to events
- In your platform’s admin or via its API, register the endpoint and select only the events you handle. Over-subscribing means parsing payloads you ignore and noisier debugging. Start with
order.createdandinventory.updated, then expand.
3. Verify the signature on every request
- This one is non-negotiable. Each payload is signed by reputable platforms with an HMAC (usually SHA-256) with a shared secret, the digest being sent in a header. Recompute the HMAC over the raw request body, and compare to the header with a constant-time comparison. If it does not match reject with 401 and do not process. Skip this and anyone who knows your URL can forge orders or stock changes at will.
4. Respond fast, process later
- Acknowledge with a
200(or any 2xx) as quickly as you can, ideally well under the platform’s timeout, which is often only a few seconds. Do not do the heavy work (ERP write, email, channel sync) inside the request. Drop the verified payload onto a queue, return immediately, then process asynchronously. Slow handlers are the number-one cause of “missing” webhooks. Here’s what actually happens: the sender times out, marks the delivery failed, retries, and now you’re processing the same payload two and three times over while your queue backs up. The webhook wasn’t missing. Your handler was just too slow to say “got it.”
5. Make processing idempotent
Because retries happen, you will receive duplicates. Every well-designed payload carries a unique event ID. Store the IDs you’ve processed and skip any you’ve already handled. Idempotency turns “at-least-once delivery” (what webhooks actually guarantee) into “effectively exactly-once” in your system. The official guidance from Stripe on building webhook handlers is an excellent, platform-agnostic reference for the verify-respond-fast-idempotent pattern.
6. Handle ordering and reconcile
- Webhooks aren’t guaranteed to arrive in order. An
order.paidcan land beforeorder.createdif deliveries race. Lean on the timestamps in the payload, fetch current state from the API when an event implies a record you haven’t seen, and run a periodic reconciliation job to repair any drift.
Reliability patterns that separate toy from production
A demo webhook is ten lines of code. A production one survives outages, deploys, and bad actors. These are the patterns we hold ourselves to on the platform.
Retries and dead-letter queues
- Senders retry failed deliveries on a backoff schedule, but they give up eventually. On the receiving side, if your async processing fails after the queue picks it up, route the message to a dead-letter queue rather than dropping it. Then alert on dead-letter depth. A growing DLQ is the earliest signal you’ll get that a downstream system has broken.
Logging and replay
- Persist every raw payload (signature header included) before you process it. When something looks wrong three days later, you want the exact bytes to replay, not a guess. A replay endpoint that re-feeds a stored payload through your handler is the fastest debugging tool you can build, and the one teams always wish they’d built sooner.
Security beyond the signature
- Signature verification proves authenticity, but layer on more. Allowlist the sender’s IP ranges where the platform publishes them, reject payloads with stale timestamps to blunt replay attacks, and keep the secret out of source control. For general web-platform security hygiene, web.dev’s security guidance is a solid baseline.
Don’t trust the payload’s amounts blindly
- For anything money- or stock-critical, treat the webhook as a signal to act, then read the authoritative value back from the API before you commit. Webhooks tell you “an order was paid”; the API tells you the canonical amount and current stock count. This belt-and-suspenders approach keeps you from acting on a stale or replayed event.
Webhooks in a multi-vendor marketplace
Marketplaces add a fan-out dimension. One inventory change may need to reach the vendor’s dashboard, the buyer-facing storefront, any connected external channels, and the central reporting layer. The clean pattern is a single internal event bus. Your webhook receiver verifies and normalizes the incoming event once, then publishes it internally so each consumer (vendor notification, channel sync, analytics) subscribes on its own. This keeps the public-facing receiver thin and makes adding a new consumer a non-event.
It also isolates blast radius. If the analytics consumer is down, order fulfillment still proceeds, because they both read from the same bus independently. If you’re designing this layer from scratch, our headless commerce implementation guide walks through the surrounding architecture, and the REST vs GraphQL API comparison helps you choose how consumers read authoritative state back.
Common mistakes to avoid
- Doing heavy work in the handler. Always queue and return fast.
- Skipping signature verification “for now.” It never gets added later.
- Assuming exactly-once delivery. Build idempotency from day one.
- Assuming ordered delivery. Use timestamps and reconcile.
- No reconciliation fallback. A missed webhook with no nightly repair means silent, permanent drift.
- Logging nothing. Without raw payloads you cannot debug or replay.
Get those six right and your order and stock sync will hold up under real traffic. If you’d rather have these patterns built in than hand-roll them yourself, Wcart ships webhook delivery, signing, retries, and reconciliation as part of the platform.
Frequently asked questions
Related guides
- Headless Commerce Implementation: A Step-by-Step Guide (hub)
- Ecommerce REST vs GraphQL API: Which to Use When
- How to Connect Your Store to an ERP or Accounting System
Leave a Reply