WooCommerce ERP Integration

WooCommerce differs from hosted platforms in one fundamental way: it runs on infrastructure you (or your host) operate. That gives you full control and full responsibility. An ERP integration with WooCommerce must account not only for the API, but for the WordPress site’s performance, its scheduled tasks, and the plugins that modify orders and products. As on every platform page, documented marks statements from WooCommerce or WordPress documentation, and recommendation marks our guidance.

How WooCommerce connects to an ERP

Documented: WooCommerce exposes a REST API under /wp-json/wc/v3 for products, variations, orders, refunds, customers, coupons, and webhooks. Over HTTPS, clients authenticate with a consumer key and secret using HTTP Basic Auth; over plain HTTP, OAuth 1.0a one-legged signatures are required. Collection responses include X-WP-Total and X-WP-TotalPages headers and Link headers for pagination.

Documented: webhooks can be configured for topics such as order.created, order.updated, product.updated, and others, delivered as POST requests with headers including X-WC-Webhook-Topic, X-WC-Webhook-Resource, X-WC-Webhook-Event, X-WC-Webhook-Signature, X-WC-Webhook-ID, and X-WC-Webhook-Delivery-ID.

Recommendation: run the integration as an external service that receives webhooks and calls the REST API, rather than as code executing inside WordPress page requests.

Common integration use cases

• Exporting orders to the ERP for fulfillment and accounting.
• Publishing stock levels and prices from the ERP.
• Creating or updating products and variations from the ERP or a PIM.
• Writing order status and tracking information back to WooCommerce.
• Recording refunds as ERP credit notes.

Order synchronization

Documented: orders are available through the orders endpoint; refunds are a sub-resource of orders. Since WooCommerce 8.2, High-Performance Order Storage (HPOS) — dedicated order tables instead of WordPress posts — is enabled by default for new installations.

Recommendation: trigger exports from order.created or order.updated webhooks filtered by status (for example, processing for paid orders), fetch the order through the API, and store the WooCommerce order ID as a unique external reference in the ERP. Because many plugins change order data (payment gateways, subscriptions, custom fields), test your mapping with the actual plugin set used in production.

Inventory synchronization

Documented: products and variations expose stock fields such as manage_stock, stock_quantity, and stock_status, and batch endpoints accept up to 100 objects per request by default.

Recommendation: use batch updates for inventory pushes to reduce request counts, update variations at the variation level, and account for orders not yet exported to the ERP when publishing quantities. WooCommerce core has no multi-location inventory model; if you need per-warehouse stock on the storefront, that depends on a plugin, and the plugin’s API becomes part of your integration surface.

Product and variant synchronization

Documented: variable products contain variations, each with its own SKU, price, and stock fields, managed through the product variations endpoints.

Recommendation: map each variation (and each simple product) to one ERP article by SKU. WooCommerce allows SKUs to be left empty; enforce non-empty, unique SKUs as a catalog rule before products go live. See mapping products to ERP SKUs.

Customer data synchronization

Documented: customers are available through the customers endpoint; guest orders carry billing and shipping details on the order without a customer account.

Recommendation: decide how guest orders map in the ERP (often a generic web customer), and match registered B2B customers on a stable ID rather than email.

Fulfillment and shipment updates

Documented: order status and order notes can be updated through the REST API.

Recommendation: WooCommerce core has no dedicated shipment-tracking object. Tracking is usually stored by a shipment-tracking plugin or in order metadata, which is how the integration should write it. Choose the plugin first, then design the integration around its data model, and set the order to completed only after shipment.

API and webhook considerations

Documented:

• Webhook payloads are signed with X-WC-Webhook-Signature, a base64-encoded HMAC-SHA256 of the payload using the webhook’s secret.
• A webhook is disabled after five consecutive failed deliveries (non-2xx) and must be edited to re-enable it.
• Webhook status values are active, paused, and disabled.

Recommendation:

• Verify signatures on the raw body with a constant-time comparison, as with any webhook.
• Monitor webhook status and alert when a webhook becomes disabled.
• Webhook delivery is driven by WordPress’s background processing, so timing depends on site traffic and how scheduled tasks are configured on your hosting. Reconcile with a scheduled query for orders modified since a checkpoint.
• Rate limits depend on your hosting and any security plugins or web application firewall in front of the site. Coordinate with your host before running large syncs.

Common implementation challenges

• Webhooks silently disabled after a receiver outage.
• Performance: large API syncs compete with shoppers for the same server resources.
• Plugin interference: caching, security, or multilingual plugins changing API responses or blocking requests.
• Direct database integrations that break with HPOS.
• Empty or duplicate SKUs causing unmappable orders.
• Inconsistent tax setups between WooCommerce and the ERP.

Direct integration vs. middleware

ERP connectors for WooCommerce exist as plugins and as middleware products; for a custom ERP, a custom external service is common. Plugins that call the ERP synchronously during checkout or admin actions are the riskiest pattern, because ERP slowness becomes store slowness. See the direct vs. middleware comparison.