Somewhere in your operation there is a person who receives an order notification from WooCommerce, opens the ERP in another window, and types the same customer name, the same address, the same three line items a second time. They are fast at it. That's the problem — competence hides cost. Multiply that by two hundred orders a month, add the stock discrepancies nobody catches until the shelf is empty, and you have the real reason your online store stops scaling at a certain point.
Integration is not a feature. It is the removal of a recurring manual task that grows linearly with revenue while your headcount doesn't. As Semplisio puts it, connecting WooCommerce to your management software lets you handle warehouse, orders, items and customers quickly and fluidly between the two systems. That's the entire proposition, and it's enough.
Technically, what you're building is a data exchange layer between the shop and the ERP, keeping information synchronised on both sides — Atlantis Evo frames it the same way. According to Daobox, the four processes you can automate this way — orders, invoicing, warehouse, customers — are precisely the four that carry the heaviest manual workload in a typical store. That correlation is not a coincidence; it's the business case.
What follows is a technical guide and, more usefully, a catalogue of the mistakes I've watched buyers make. It applies whether you sell components, run a warehouse management system built for shops, or handle event ticketing where the "stock" is seats and the deadline is absolute.
Obly reduces the problem to three decisions: what to synchronise, in which direction, and by which method. I would sign that framework without amendment. Every failed integration I've audited went wrong at decision one or two, never at the code.
Products, prices, stock, orders, customers, invoices. You do not need all six on day one, and the teams that insist otherwise are the ones still in testing eight months later. Pick a minimum viable set — stock and orders usually — and defer the rest until the first set has run clean for a month.
One-way ERP → shop is the safest. One-way shop → ERP is nearly as safe. Bidirectional on the same entity is where you invite race conditions, sync loops and the delightful phenomenon of a price that flips back and forth every fifteen minutes because two systems each believe they're right.
This is the architectural decision that outlives everyone in the room. For each entity — not globally — name one system as authoritative. Typically the ERP owns products, prices and stock; WooCommerce owns orders and the customer account. Write it down, because in month eighteen someone will ask and the original integrator will no longer be reachable.
Real-time webhooks for orders, scheduled batch jobs for catalogue. Stock sits in between and depends on how close you run to zero. If you regularly sell the last unit, you need near-real-time; if you hold depth, a fifteen-minute cycle saves you a great deal of API traffic.
Obly's taxonomy of three possible methods maps neatly onto three procurement profiles.
Fastest and cheapest, typically a few hundred euros a year. The constraint is that it only speaks to supported ERPs and its field mapping is rigid. Fine if your catalogue is standard and your ERP is one of the mainstream Italian names. Less fine when you discover that your custom price-list logic has no field to live in, and the vendor's answer is a feature request queue.
A transformation layer with queuing and retries, which matters more than it sounds — retries are what stop a five-minute ERP outage from silently losing eleven orders. Worth it if you sell on multiple channels. Watch the pricing model: most iPaaS vendors bill per task or per run, and a catalogue sync of 8,000 SKUs is not one task.
Total control over field mapping and business rules, and the only route when the ERP is bespoke or twenty years old. Gogodigital confirms that even custom ERPs can be synchronised for orders, customers and products. The cost is upfront development plus maintenance you must budget for; the benefit is no vendor between you and your own data. If you're building custom anyway, it's worth checking whether the work falls under custom software and Transizione 5.0 incentives.
Decide on four variables: number of SKUs, monthly order volume, how open your ERP's API is, and whether you have in-house development capacity that will still exist next year. That last one disqualifies more custom builds than any technical factor.
The REST API is the reason WooCommerce is integrable with practically anything. As this technical walkthrough notes, the work isn't especially complex — it just requires actually knowing the WP REST APIs, which is a different sentence from "anyone can do it."
Consumer key and secret, HTTPS only, and permissions scoped to read or read-write as the direction requires. Do not issue a read-write key to a process that only pulls the catalogue. Rotate keys when an admin leaves — admin handover is where credentials quietly become permanent.
Products, variations, stock, orders, customers. Add webhooks on order.created and order.updated so the ERP is pushed to rather than polling. Atlantis Evo's step-by-step guide is a reasonable companion if you want the sequence spelled out.
Idempotency keys, so a retried webhook doesn't create a duplicate order. An external ID mapping table, so ERP record 44821 and WooCommerce product 3117 are permanently married. Pagination discipline, because a 12,000-SKU catalogue pulled in one request will time out and your host will not be sympathetic.
Linkware is right to insist on verifying prerequisites before starting. My version of that list:
If your operation involves shipping and picking, cross-check against the logistics software features SMEs need before you finalise scope.
Linkware states it plainly, and it deserves quoting: customer data transits between two systems, so you must document the flows in the record of processing activities, verify that the ERP respects the same security measures as the online store, and provide for coherent deletion procedures. Three obligations, all of them auditable, none of them optional.
In practice: encryption, access control and backups on the ERP side must match what you promise on the shop side — the weaker system defines your actual posture. An erasure request received through WooCommerce must propagate to the ERP, and if your integration is one-way ERP → shop, that propagation is a manual procedure someone has to own. Write the name of that someone in the procedure.
Then the paperwork: data processor agreements with the plugin vendor, the hosting provider and the integrator. And minimise the fields you sync — the ERP does not need marketing consent flags or browsing history. Every field you don't transfer is a field you never have to defend. For attendee-heavy scenarios, the same logic applies to event management apps and attendee data.
Phase 1 — read-only. ERP → shop for catalogue and stock. No writes to the ERP. The goal is trust in the data; run it two to four weeks and compare against manual counts.
Phase 2 — orders and customers. Shop → ERP, with a manual review window before records commit. Keep the window until the error rate is boring.
Phase 3 — full automation. Invoicing and returns, which is where Daobox's four automated processes finally close the loop. Define two KPIs and report them: sync error rate, and minutes saved per order. If you can't quantify the second, you'll lose the budget argument at renewal.
Maintenance. WooCommerce core and plugin updates break integrations — version-pin, keep a regression test, and confirm your integrator offers continuous support rather than a delivery-and-goodbye engagement. If the shop itself is still being built, getting a business site online quickly comes first; integrate second.
Who will regret this purchase? The owner who bought a €400/year connector because the demo synced twelve products beautifully, then discovered in month six that price lists don't map, the vendor's roadmap doesn't include them, and the only export path runs through a support ticket. Decide the three questions first. The tool is the last choice you make, not the first.
