An e-commerce and ERP integration synchronises four flows: catalogue and customer records, stock levels, orders and documents. Each field needs a single owning system, with the others read only. Webhooks provide responsiveness, a scheduled reconciliation pass provides certainty, and idempotency plus a retry queue prevent duplicate or lost orders.
A client walked us through their order process: the store sends an email, a person opens the ERP and retypes the data. Thirty orders a day, two minutes each, plus the mistakes. It worked, in the sense that the company was still standing. But that work added nothing to anything.
Connecting an online store to a management system is one of the projects with the clearest payback we get to do, and also one of the most frequently botched. The reason is that it looks like a technical problem while the hard part happens earlier.
First question: which system owns the truth
For every piece of data that lives in two systems, you have to decide which one is in charge. Does the ERP set the price, or does the store? What about stock levels? The customer record? If that map does not exist, the integration will decide for you, following the logic of whoever wrote the last script, and you end up with two systems overwriting each other in turns.
The rule that works almost always: one field, one owner, everyone else read only. Exceptions get counted and written down, not discovered in production.
The four flows that matter
Almost every integration boils down to four flows, and it pays to treat them separately because they have different frequencies and different tolerances for being wrong.
Catalogue and customer records. Usually from the ERP to the store, at a low frequency. The trap here is not technical but editorial: product descriptions written for an invoice are unreadable on a product page, so the store often needs its own fields that the sync must never touch.
Stock levels. The most delicate flow, because a mistake here means selling something you do not have. It needs to be close to real time, and it needs a policy for the awkward cases: goods reserved but not yet shipped, safety buffers on fast movers, items sold in a physical shop at the same moment.
Orders. From the store to the ERP, and this is where the mapping work hides: payment methods, tax rates, shipping costs as a line item, discount codes, split shipments. An order that the ERP refuses has to end up somewhere visible, not in a log nobody opens.
Documents and shipping. The return leg: invoice, delivery note, tracking number, status changes that trigger emails to the customer. Returns and credit notes belong here too, and they are the part that gets postponed and then handled by hand for two years.
Syncing without breaking anything
Three mechanisms, in order of preference: webhooks, where the store tells you something happened and you react; polling, where you ask every few minutes what changed; batch files, the last resort. Anyone going live on webhooks alone will eventually lose an event, because a notification always gets lost somewhere. You keep the webhook for responsiveness and add a nightly reconciliation pass for certainty.
Two things are not negotiable. Idempotency: the same notification processed twice must not create two orders, so every record carries the other system's identifier. And a queue with retries and visible failures: when the ERP is down for the nightly backup, orders pile up and then flow, they do not evaporate.
When the ERP has no decent API
Half the management systems we meet have no API designed for this. The ways out, in decreasing order of elegance: an API that exists but is undocumented, which is more common than vendors admit because their own mobile module uses it; a read-only view on the database plus a staging table for writes; a file exchange over a shared folder or FTP with an agreed format. All three work. What makes the difference is agreeing on the contract in writing beforehand, because an integration leaning on an internal detail breaks silently the day the vendor ships an update.
The worst case is a system nobody maintains any more, where every change goes through a consultant who answers in weeks. At that point the integration project becomes the occasion for a different question, one we have looked at elsewhere: what is that system actually costing you.
Middleware, yes or no
With two systems and four flows, a direct connector is easier to understand and to maintain. Middleware starts paying for itself when there are three or more endpoints, say store, ERP, third-party warehouse and a marketplace, because it gives you one place to read logs and one place to change data transformations. Buying an integration platform for two systems is a fixed cost paid for a problem you do not have yet.
The questions we ask before starting
Four answers, and they are almost always the same four. Which data has to move, and in which direction. How stale a value can be before it becomes a problem, since stock at five minutes is fine and at one hour is not, and that single answer changes the architecture. What should happen when one system is down. Who looks at the errors the next morning. With those in hand, the code is the least risky part of the project.
We do this work on both sides of the wire, from the store to the systems behind it. If you are retyping orders today, that is the cheapest problem on this list to remove.
