Proven patterns for integrating iDempiere ERP with Shopify, WooCommerce, BigCommerce and WinxCommerce — what to sync, how to sync it, the edge cases nobody tells you about, and monitoring that catches failures before customers complain.
Grouped by the decision each section supports. Jump straight to the part you need.
If your eCommerce store lives in Shopify (or WooCommerce, BigCommerce, WinxCommerce) and your accounting, inventory, and fulfillment live in iDempiere, you are either double-keying orders or living with stale data. Neither scales.
A well-designed integration makes iDempiere the single source of truth for master data (products, prices, inventory) and the system of record for financial transactions (orders → invoices → payments → GL). Your storefront becomes a sales channel, not a data island.
The integration scope we recommend for 95% of clients:
| Entity | Direction | Frequency |
|---|---|---|
| Products (catalog) | iDempiere → Shopify | On change + daily full sync |
| Prices / price lists | iDempiere → Shopify | On change |
| Inventory / stock | iDempiere → Shopify | Near real-time (every 5 min) |
| Orders | Shopify → iDempiere | Webhook (real-time) |
| Customers | Bi-directional (Shopify → iDempiere primary) | On order creation |
| Fulfillment status | iDempiere → Shopify | On shipment confirmation |
| Invoices | Generated in iDempiere, emailed / displayed to customer | On invoice |
The ERP side of the integration barely changes between platforms. What changes is how you authenticate, how orders reach you, and who is responsible when the store goes down.
| Aspect | Shopify | WooCommerce | BigCommerce |
|---|---|---|---|
| Hosting model | Fully hosted SaaS | Self-hosted on your WordPress | Fully hosted SaaS |
| API | Admin API, REST and GraphQL | REST API, versioned | REST and GraphQL |
| Authentication | App access token | Consumer key and secret over HTTPS | OAuth access token |
| Order notification | Webhooks, reliable | Webhooks, dependent on your own site being up | Webhooks |
| Multi-warehouse stock | Native Locations, map one-to-one to iDempiere warehouses | Needs a plugin; behaviour varies by plugin | Native multi-location |
| Rate limits | Enforced and documented; design for them | Bounded by your own server | Enforced and documented |
| Who fixes an outage | The platform | You, or your hosting provider | The platform |
| Integration effort | Lowest — consistent, well-documented behaviour | Varies with your plugin stack | Low |
WinxCommerce and other platforms follow the same pattern. Where a platform exposes a documented REST API and webhooks, the iDempiere side is unchanged and only the adapter differs. Storefront APIs are versioned and do change — confirm the current contract before scoping a build.
We build this as an OSGi plugin inside iDempiere plus a thin middleware layer (a Spring Boot service or serverless functions) depending on volume. Key components:
Product master lives in iDempiere. When a product changes, a model validator fires an outbound message and the middleware maps ERP fields onto storefront fields.
| iDempiere | Storefront | Notes |
|---|---|---|
M_Product.Value | product handle and variant SKU | The join key for everything else. Never let it change after go-live. |
M_Product.Name | product title | Merchandising teams often want a different title online — decide who wins before you build. |
M_Product.Description | product body / description | HTML from the ERP needs sanitising before it reaches the storefront. |
M_PriceList price | variant price | Currency-specific. One price list per storefront and currency keeps this unambiguous. |
M_Attachment images | product images | Push order matters; the first image is usually the one the store shows in listings. |
| Attribute Sets (size, colour) | product options and variants | Requires attribute discipline in the ERP. Without it, variant sync falls apart within weeks. |
M_StorageOnHand per warehouse | inventory level per location | Map warehouses to store locations one-to-one and send absolute quantities. |
The single most common cause of a failed catalogue sync is inconsistent product coding in the ERP. Fix that before the integration, not during it — it is cheaper and it improves the ERP regardless of what you connect to it.
Inventory is the spicy part. iDempiere's M_StorageOnHand is your source of truth per warehouse. Shopify has inventory_levels per Location. Map iDempiere warehouses to Shopify locations 1:1.
Two modes:
Always send absolute quantities, not deltas. Delta-based syncs drift; absolute-quantity syncs self-heal.
A webhook fires the moment a customer checks out. Within seconds the order exists in the ERP as a real document, not a staging record.
A customer record is created if this is a new buyer, or matched to an existing one. This is the step where duplicates are prevented rather than cleaned up later.
A standard sales order against the correct sales channel, so web revenue can always be separated from trade and retail in reporting.
Product, quantity and price per line, with tax recomputed by the ERP's own rules rather than carried across from the storefront.
Where the order was paid at checkout, the payment is recorded and allocated, so the receivable never appears open for an order that is already settled.
When the warehouse ships, the ERP generates the shipment and invoice, posts to the ledger, and sends the fulfilment update with carrier and tracking number back to the storefront so the customer sees it.
Deduplication is the hardest problem. We match on email first, then phone, then name + pincode. New customers get a C_BPartner record with a generated customer code. Existing customers get their address list merged, not overwritten.
B2B customers with GSTIN / VAT-ID on the storefront need special handling — we validate the tax ID against the official registry (GSTN, HMRC, etc.) before creating the tax-included invoice.
Every one of these is cheap to design around and expensive to discover in production.
Hundreds of orders in a minute will overwhelm a naive listener. Acknowledge the webhook immediately, process asynchronously, raise worker concurrency for the event, and make sure nothing is lost if a worker dies mid-order.
Never post the storefront's calculated tax straight to the invoice. Let the ERP recompute with your own place-of-supply and registration rules, and reconcile the difference rather than inheriting it.
Ship eight of ten items and the fulfilment payload must match the shipment lines exactly, or the customer is told the wrong things have shipped. Model partial shipments properly from the start.
Returns belong in their own documents: authorisation, return shipment, credit note. Editing the original order destroys the audit trail and makes any historical financial position impossible to rebuild.
If a second storefront or marketplace is even possible, make sales channel a first-class dimension on day one. Retrofitting it across orders, stock and reporting after go-live is a project in its own right.
Sending adjustments rather than absolute quantities means one missed message silently corrupts the figure forever. Absolute quantities self-heal on the next sync; deltas drift until somebody notices an oversell.
Build the dashboard before you go live. Minimum KPIs:
We wire these into Grafana or Power BI and alert on anomalies. Customers notice inventory-sync failures faster than you do — don't let them tell you first.
We've built and run these integrations in production for 50+ clients. Get a free architecture review and a fixed-price proposal.
What operations and finance teams ask before an eCommerce integration starts.
Six pages cover iDempiere here, each answering a different question — the practice, choosing a partner, what it costs, and the three integrations clients ask for most. Whichever you landed on, the rest are one click away.
Get a free Proof of Concept — we build a working iDempiere environment with your data, modules, and integrations in 2–3 weeks. Zero upfront cost, zero obligation.
