Use WooCommerce webhooks to keep inventory synchronized with marketplaces

If stock drifting between your WooCommerce store and a marketplace or POS is costing you time or orders, start by wiring one reliable webhook and a simple reconciliation check. Webhooks tell a receiver when products or orders change; they’re the easiest official trigger for external updates, but they must be configured, tested and verified.

In this guide

• Understand webhook topics and payloads
• Choose which events should trigger updates
• Create the webhook (Admin UI or REST API)
• Secure and verify incoming requests
• Delivery reliability and what WooCommerce documents
• Test end-to-end on your site
• Operational pattern: reconciliation and fallbacks
• Quick decision checklist

Understand webhook topics and payloads

WooCommerce sends topic-based webhooks such as product.updated, order.created and action/custom topics. The webhook body follows the REST API resource representation, so the JSON you receive matches the canonical product or order resource from the WooCommerce REST API. See the official overview for topics, the admin flow and delivery logs: WooCommerce webhooks documentation, and the REST API webhooks reference showing headers and payload details: WooCommerce REST API v3 webhooks.

Choose which events should trigger updates

Map each external update you need (adjust stock, remove listings, update price) to one or more webhook topics. For inventory sync the common choices are:

• order.created — reduce available stock after a confirmed order;
• product.updated — a supplier or admin changed stock_quantity or stock_status;
• product.deleted — remove the item from marketplaces.

Don’t assume a single topic covers everything: product updates can include many fields and sometimes a change to stock is performed by an order, not an explicit product edit. Confirm the payload contains the fields your receiver needs by comparing a test delivery with the REST API resource representation: WooCommerce REST API overview.

Create the webhook (Admin UI or REST API)

You can create webhooks from the admin or programmatically. The admin path is WooCommerce > Settings > Advanced > Webhooks. The REST API endpoint to create a webhook is POST /wp-json/wc/v3/webhooks — both methods let you set Topic, Delivery URL and an optional secret. Official docs for the admin location and REST endpoint are here: Advanced settings (admin) and REST API v3 webhooks.

Copyable REST example (minimal fields). Adjust names, topic and delivery_url for your site; include a secret if you plan to verify signatures on the receiver.

curl -X POST https://your-site.example/wp-json/wc/v3/webhooks \
  -u ck_yourkey:cs_yoursecret \
  -H 'Content-Type: application/json' \
  -d '{
    "name": "Inventory webhook",
    "topic": "product.updated",
    "delivery_url": "https://hooks.example.com/your-receiver",
    "secret": "choose-a-long-random-string",
    "status": "active"
  }'

Secure and verify incoming requests

Use HTTPS endpoints and set the webhook Secret so WooCommerce can sign deliveries. Incoming requests include headers such as X-WC-Webhook-Signature, X-WC-Webhook-Topic and X-WC-Webhook-Delivery-ID. Verify the signature on the receiver using the documented approach in the REST API webhooks reference: Webhook headers and signature. Also follow the admin docs for the normal creation and logging workflow: Webhooks admin documentation.

On the receiver side implement simple checks before applying inventory changes: validate the signature, confirm the topic matches your mapping, and parse the delivery ID so duplicate deliveries are detectable.

Delivery reliability and what WooCommerce documents

WooCommerce delivers webhooks via background scheduled actions (wp-cron/scheduled actions); that affects timing and retry behaviour. The docs note delivery attempts, logging and that a webhook is automatically disabled after a number of consecutive failures — the official pages describe logs and the disable behaviour but do not publish exact retry intervals or host-level SLAs. Read the background jobs note and webhook behaviour here: WooCommerce background scheduled actions and REST API v3 webhooks (delivery & headers).

Design receivers to be idempotent and tolerant of duplicate deliveries or delayed messages. That means: ignore a duplicate delivery-id, apply stock changes by checking the current product record and using the delivery payload only to drive an update transactionally, and always log the webhook body and response for debugging.

Test end-to-end on your site

1. Create a test receiver you control — a simple HTTPS logging endpoint that records the full JSON and headers.
2. Create a webhook in WooCommerce pointing at that test URL (admin UI is fastest for the first check).
3. Trigger events: edit a product’s stock_quantity in the admin or create a test order that consumes stock. The product.updated and order.created topics should then post to your receiver.
4. Confirm two things: your receiver logged a valid JSON payload and headers, and WooCommerce shows a successful delivery or the initial ping in its logs. See the admin docs for where WooCommerce surfaces delivery logs: Webhooks documentation (delivery logs).

Observing the JSON and the signature header is the observable check: if both appear and the signature verifies, your receiver can proceed to update the marketplace/POS. If deliveries fail, inspect WooCommerce logs and the receiver logs to diagnose network, TLS or application errors.

Operational pattern: reconciliation and fallbacks

Treat webhooks as near-real-time notifications, not a sole source of truth. Implement a periodic reconciliation job that polls the WooCommerce REST API for product stock (GET /wp-json/wc/v3/products or a product SKU endpoint) and compares it against the marketplace state. If mismatches are found, correct them or raise alerts. The REST API is the canonical resource representation for reconciliation: WooCommerce REST API reference.

This pattern protects you from missed deliveries, backend delays caused by scheduled actions, or hosting outages that block webhook delivery. Use batching for high-volume updates and backoff-friendly flows when a marketplace supports it.

Quick decision checklist

• Create one test webhook to a controlled HTTPS endpoint and set a secret.
• Trigger a stock change (admin edit or test order) and confirm webhook payload + signature arrive.
• Implement signature verification and idempotent handling on the receiver.
• Enable delivery logging and monitor WooCommerce > Status > Logs for disabled webhooks.
• Schedule a daily or hourly reconciliation job via the REST API for critical SKUs.

When you’ve run the test and seen matching logs at both ends, you’ll know the webhook path is usable and can move to add the marketplace logic (translate payload fields to the marketplace API calls, handle rate limits and map SKUs).

Related guides: Create and troubleshoot a Google Merchant product feed from WooCommerce and Your WordPress backup exists. Can you restore it?

Next action: in your admin, create a single product.updated webhook to a logging endpoint you control, trigger a stock edit and confirm both the receiver log and WooCommerce delivery record show the JSON and signature headers.