WooCommerce integrations with ERP and wholesale APIs

#WooCommerce integrations with ERP and wholesale APIs

If you need general help building and growing a store, start with the WooCommerce developer page. For the broader architecture picture (headless, ERP, and AI-ready data), see enterprise solutions. This page is about a narrower, more technical problem: exchanging data between WooCommerce and external systems.

#What a WooCommerce integration actually is

In most stores the truth about products does not live in WooCommerce. It lives in the ERP, in the warehouse system or in a wholesaler API. WooCommerce is the sales front, but stock, prices and part of the product data come from elsewhere. An integration is the layer that keeps those two worlds in agreement.

In practice an integration answers three questions:

• What we synchronise - catalog, attributes, stock levels, prices, orders, customer data.
• Which direction - one-way (the source system dictates to the store) or two-way (for example, orders flow back to the ERP).
• How often - from scheduled polling every few minutes to event-driven updates over webhooks.

#What you can integrate with WooCommerce

You do not have to do everything at once. The most common first step is stock and price sync, because it pays back fastest in recovered support time and avoided refunds.

#How data synchronisation works

The mechanics are similar everywhere, whether the source is an ERP or a wholesaler API. The source differs, not the principle.

#Data mapping

The source system describes products with its own field structure. The first job of an integration is to translate that into the WooCommerce product and attribute model: EAN and index as the keys that link records, technical attributes onto attributes and variations, media and descriptions onto product pages. We keep the field map declarative, so adding a new parameter means extending the mapping, not rewriting the logic.

#Stock and price synchronisation

The core of most integrations is scheduled polling for two things: stock level and price. Items unavailable in the source system are automatically hidden or marked unavailable, which removes the most expensive failure a store can make - selling something that cannot be fulfilled. A price change in the source system propagates to the store on the next cycle.

#Margin logic

Prices from an ERP or wholesaler are usually cost, not the selling price. Above the data-pull layer sits margin logic: the system applies a defined margin over the source price, and only the result reaches WooCommerce. The owner steers profitability with rules, not by editing prices by hand.

#A real integration

The same mechanics sit behind our project for an automotive parts store wired directly to a wholesaler REST API: WooCommerce wholesale API integration. There the catalog, stock and prices keep themselves current, and margin protects profitability against a moving supplier list.

#Which ERP systems we integrate with

An important distinction: we integrate WooCommerce with the API of these systems, we do not implement the ERP itself. This is WordPress, PHP and data-exchange work, not ERP consultancy.

• Cloud ERP: Microsoft Dynamics 365 Business Central, SAP Business One, Oracle NetSuite, Odoo. These expose REST APIs, which keeps the store connection clean.
• Regional accounting and ERP: systems like Sage, Xero or DATEV depending on the market, usually integrated through their API or a middleware layer.

If your system is not on the list but has any API or data export, it can usually be integrated.

#How we architect integrations for specific ERPs

Every ERP has its own API, data format and traps. Below is how we approach the most common systems. These are architecture patterns, not a plugin bought for a few dollars.

#SAP Business One - scale and the wp_postmeta problem

Industrial distribution: tens of thousands of active products, frequent price updates (several times a day when currency rates move), hundreds of attributes. WordPress’s default EAV structure stores every attribute in wp_postmeta, which at that scale swells to millions of rows; real-time price updates then cause MySQL deadlocks and 504 timeouts for shoppers.

• HPOS and custom tables: we stop writing attributes to wp_postmeta and use a dedicated flat MySQL table built for SAP B1 queries.
• Elasticsearch as the search layer: SAP updates data in Elasticsearch via API and the front pulls results and filters from there, bypassing MySQL. The objective is predictable catalogue search without making the transactional database answer every filtering request.
• Queueing (RabbitMQ): SAP updates land in a message queue and a background worker pulls batches of a few hundred products at a time, keeping the store responsive 24/7.

#Microsoft Dynamics 365 (with BaseLinker and POS)

A large retailer selling through WooCommerce, marketplaces (via BaseLinker) and physical stores with a POS on Dynamics 365. Without a strict hierarchy you get sync loops and race conditions (the last unit sold in-store and a second later on a marketplace), producing negative stock.

• Single source of truth: we enforce a hierarchy where Dynamics is the absolute master and WooCommerce and BaseLinker are slaves.
• Redis layer: instead of polling the Dynamics API constantly, we can maintain a short-lived availability view in Redis. An in-store sale fires a webhook that updates that view, and WooCommerce and BaseLinker check it before finalising a cart. Reservations and reconciliation remain necessary because no cache can guarantee that every external channel updates successfully.

#Odoo (open source) - made-to-order configurators

Manufacturers configure products in Odoo (a bill of materials) where a component’s price depends on other choices. WooCommerce variations cannot model that, and porting the production logic into PHP produces unmaintainable code.

• Decoupled / headless approach: WooCommerce is the cart and transaction system (payment, emails), while the frontend (Astro/Vue) talks directly to the Odoo API, asking for pricing and production feasibility on the fly. On “add to cart” a custom product with an Odoo-computed price and a generated spec PDF is sent to WooCommerce, without duplicating the business logic.

#Comarch Optima, InsERT Subiekt, enova365 (Polish and CEE market)

• Comarch Optima: where the available interface exposes change information, we build dedicated PHP middleware and use differential (delta) sync - a scheduled job asks only for indexes changed in the last window rather than importing the complete catalogue every time. B2B prices can be computed from the customer’s discount group rather than stored as a separate variation for every possible price.
• InsERT Subiekt GT / nexo: data exchange over EPP and API; a hard reservation locks stock in Subiekt for a few minutes at checkout to prevent overselling during peaks, and a correction document fires a webhook that flips the WooCommerce order to returned and restocks the item.
• enova365: for high-variant-count products (colours x sizes, each with its own EAN) we use flat variants mapped to JSON and loaded asynchronously over REST, instead of generating hundreds of thousands of product_variation posts.

#JTL-Wawi (Germany) and Holded (Spain)

• JTL-Wawi: omnichannel with multi-warehouse. Logic routing analyses the customer’s postcode and algorithmically picks the fastest-shipping warehouse; One Stop Shop handling recomputes VAT on the fly by destination country so the invoice in JTL carries the correct rate. WooCommerce runs in parallel with BaseLinker for Amazon and eBay.
• Holded: a cloud, API-first ERP - a fully file-free integration on the native REST API with token auth and webhooks. Invoice logic recognises the cart amount and flags Holded to generate the correct document type (for example a simplified invoice for small amounts), returning a PDF to attach to the WooCommerce email.

#Enterprise architecture: performance and reliability

At large ERP scale we move past “install a plugin.” This is hard engineering:

• Headless / decoupled: WordPress is the admin engine (backend) and the store renders in Astro or Next.js, hitting a GraphQL or REST API and bypassing slow SQL, which makes the store faster and more resilient. More in enterprise solutions.
• Asynchronous processing (queues): syncing tens of thousands of products in a plain PHP script times out. We base it on queues (RabbitMQ or Redis) that process small chunks in the background.
• Error handling and logging: if the ERP API does not respond, we block checkout with a message rather than accept orders into a void; full error logging enables fast diagnosis.

#Technical problems we solve

• API rate limiting (429): cloud systems cap requests. We implement exponential backoff (on a 429 the script waits and retries) plus chunking, packing data into bulk-update JSON requests instead of thousands of single calls.
• Data-type mismatches (rounding): an ERP may hold prices to four decimals while WooCommerce expects two. In the middleware we apply strict type casting and reconcile rounding per invoice line, avoiding penny errors that compound across hundreds of orders.
• Images, bandwidth and the inode limit: importing physical images into the WordPress media library (generating several thumbnails each) exhausts the server’s file limit. Instead we serve images from external storage (Amazon S3 or Cloudflare Image Resizing) via URLs mapped from the ERP, saving space and speeding up the sync itself.

#Discovery starts with system boundaries, not endpoints

Before writing middleware, we establish which system owns each business fact. A diagram that merely connects WooCommerce to an ERP is not enough. We need to know who may create a product, where an SKU can change, which system owns tax classes, whether a warehouse reservation is authoritative, and who is allowed to correct an order after payment. If two systems can independently edit the same field, the integration needs a conflict rule rather than another API call.

The discovery output is a boundary map and a data contract. The boundary map names the source of truth for products, variants, stock, prices, customers, orders, fulfilment and invoices. The contract records identifiers, required fields, allowed values, direction, cadence, retry behaviour and the treatment of deleted or incomplete records. We also identify personal data and credentials so they are not copied into logs or secondary systems without a reason.

We then walk through real operational scenarios with the people who use the systems. Examples include a new product without an image, a renamed SKU, stock split across warehouses, a customer-specific B2B price, a partially fulfilled order, a refund and a supplier API outage. This reveals rules that API documentation rarely contains. It also lets us separate the first releasable flow from optional automation, keeping the initial integration testable and commercially useful.

#Failure modes for catalogue, stock, price and order sync

Catalogue sync can fail quietly. A parent product may arrive after its variants, an attribute can change type, an image URL may expire, or two records can share an EAN. We quarantine invalid records instead of publishing partial products. The import report identifies the source record, validation failure and proposed action, while a later run can safely retry it after correction.

Stock requires a time model. “Available” can mean physical quantity, quantity after reservations, or quantity after a safety buffer. Webhooks can arrive twice or out of order, and polling can overlap with checkout. We therefore use idempotent messages, version or timestamp checks where the source supports them, reservation rules and scheduled reconciliation. When the source is unavailable, the agreed policy may freeze the last confirmed quantity, apply a conservative buffer or temporarily prevent purchase. That choice belongs in the acceptance criteria.

Price sync has its own hazards: net versus gross values, VAT jurisdiction, currencies, customer groups, promotional periods, rounding and minimum margin. We calculate from explicit inputs and retain the rule version that produced the storefront price. A surprising price is then traceable to source data and a rule, not hidden inside an unexplained update.

Order export must be safe to repeat. A timeout after submission does not prove that the ERP rejected an order, so a blind retry can create a duplicate. We assign a stable external reference, check the target before retrying, and record acknowledgements. Address validation, payment status, shipping lines, discounts, refunds, cancellations and partial fulfilment are modelled explicitly. Failed orders enter an actionable queue; they do not disappear into a generic log.

#Acceptance evidence before launch

Acceptance is based on evidence from a staging environment and an agreed sample of representative records. We prepare a traceability matrix that links each requirement to a test and its result. The sample covers simple and variable products, missing optional data, special characters, multiple tax treatments, stock boundaries, price changes and the full order lifecycle. Where production-like data cannot be used, anonymised fixtures preserve the same shapes and edge cases.

For each flow we retain request identifiers, timestamps, source and target identifiers, before-and-after values and the resulting status. We test duplicate delivery, delayed messages, rate limiting, invalid credentials and temporary unavailability. Reconciliation must show that the source and target agree, or produce a finite exception list that an operator can resolve. Performance is tested against the expected catalogue and update pattern, without presenting laboratory results as guaranteed production outcomes.

Launch criteria normally include approved mappings, successful critical-path tests, a reviewed rollback or pause procedure, configured monitoring, credential ownership and named operational contacts. Deployment is followed by controlled observation of the first real cycles and orders. Any exception is assessed against the agreed policy before the synchronisation scope is widened.

#Operational handover and ownership

An integration becomes part of daily operations, so handover is a deliverable rather than a closing email. We provide an architecture overview, source-of-truth matrix, mapping reference, schedule and webhook inventory, credential locations, deployment notes, monitoring rules and a runbook for common failures. Secrets stay in the appropriate secret store; the documentation explains how to rotate them without exposing their values.

Operators learn how to distinguish a source-data problem from an infrastructure problem, retry a quarantined record safely, pause a flow and verify recovery. We agree alert severity, recipients and response ownership. A dashboard should answer practical questions: when each flow last succeeded, how many records are pending or rejected, whether order export is current and whether reconciliation found drift.

Change management matters after launch. ERP upgrades, new warehouses, tax changes and WooCommerce extension updates can alter the contract. We recommend testing contract changes in staging, versioning mappings and keeping a small regression set of representative products and orders. This reduces dependence on one developer and makes future maintenance auditable.

#What to include in your written brief

Send a written brief with the store URL, ERP or supplier system and version, available API documentation, authentication method and a named technical contact for the source system. List the approximate number of products and variants, warehouses, currencies, price lists and expected update frequency. State which system currently owns catalogue, stock, price, customers, orders, invoices and fulfilment.

Describe the first business flow you need to make reliable and the failures you see today. Include sample product, stock, price and order payloads with personal data removed, plus any rate limits, sandbox access and fixed launch constraints. Note whether the existing store already has integration code or plugins. We can then return a scoped proposal with assumptions, exclusions, acceptance evidence and the information still needed, instead of estimating from a product name alone.

#When an integration is worth considering

• You update stock and prices by hand or by file import, and it does not scale.
• You get orders for products the supplier does not actually stock.
• Store prices drift away from the wholesaler or ERP price list.
• Orders have to be re-keyed into the accounting or warehouse system by hand.