WooCommerce and ERP integration: where problems most often arise
Integrating a store with an ERP system has a simple goal: the data in both systems should match without being retyped by hand. In practice, the difficulties rarely come from the API itself. More often they come from two systems understanding the same data differently.
Which data flows, and in which direction
The first question in any integration is: which system is the source of truth for a given piece of information. A typical split looks like this:
| Data | Most common source | Direction |
|---|---|---|
| Products and variants | ERP | ERP → WooCommerce |
| Prices | ERP | ERP → WooCommerce |
| Stock levels | ERP | ERP → WooCommerce |
| Orders | WooCommerce | WooCommerce → ERP |
| Order statuses | ERP | ERP → WooCommerce |
Every company may split it differently, but the split has to be agreed before any code is written.
Where integrations most often go out of sync
Product identifiers. The ERP uses its own item codes, the store has SKUs and variant IDs. Without an unambiguous mapping, synchronization starts creating duplicates or updating the wrong products.
Variants. In an ERP a variant is often a separate item; in WooCommerce it's a child of a variable product. You have to decide how this structure is built and updated.
Prices. Net and gross prices, price lists for customer groups, promotions set up in the store. If both systems can change a price, data easily gets overwritten.
Stock levels. Between synchronizations, the stock in the store can be out of date. It's worth deciding up front how often to synchronize and what happens when an item is out of stock.
Orders. An order passed to the ERP must contain everything the ERP requires: customer data, shipping method, payment, discounts. A single missing field can stop the whole process.
Synchronization: on a schedule or on events
There are two basic models:
- periodic synchronization, e.g. every few minutes or once a night, good for large catalogs and data that doesn't need to be immediate;
- event-based synchronization, e.g. a webhook after an order is placed, good where reaction time matters.
In practice, both approaches are often combined. Long operations are best run in the background, e.g. through a queue or Action Scheduler, so they don't slow the store down.
Errors are part of the integration
APIs are sometimes unavailable, data is sometimes incomplete. A good integration assumes this from the start: it keeps logs, retries failed operations and notifies the team when something needs a manual decision. That way a problem with one order doesn't stop all sales.