Integrating your ERP with your storefront without weekly breakage

"Make the storefront's stock match the ERP" sounds like an afternoon of work. In practice it's the project where most teams sink, and always on the same four decisions taken badly at the start.

Decision 1 — Who owns each piece of data

Before any code, you define field by field which system holds the truth:

Data	Usually owned by
Available stock	ERP
List price	ERP
Promotional price	Storefront
Product copy and photos	Storefront
Order	Storefront (ERP once created)
Shipment status	ERP
Customer	It depends — and it has to be decided

The rule is that every field has exactly one owner and every other system mirrors it. If two systems can write the same field, you don't have an integration — you have a race, and the winner depends on which job ran first that morning.

The customer record deserves its own attention. It causes the most trouble, because the storefront identifies people by email and the ERP by tax ID, and the same human can have three accounts in one and two in the other.

Decision 2 — How often, and triggered by what

Batch every N minutes. Simple, robust, easy to retry. Fine for prices and product copy. Not fine for the stock of an item that's running out.

Event-driven. The ERP announces changes. More immediate and more fragile: if a webhook is lost, that change is never retried.

What works in production is almost always both: events for the urgent things, plus a periodic reconciliation that compares the two sides and corrects the differences. Reconciliation isn't optional. It's what stops a silent discrepancy from compounding for three months.

Decision 3 — What to do about stock (the painful one)

This is the real problem, and it isn't technical: the ERP's stock figure is never the sellable figure.

The ERP holds units reserved for a wholesale order, units in transit between warehouses, damaged units nobody wrote off, and units on the shop floor being sold right now through a channel that isn't the website.

Publishing the raw ERP number is the guaranteed recipe for overselling. Three strategies that work:

• Safety buffer. Publish available minus N. Crude and simple, and it works surprisingly well.
• Per-channel allocation. Reserve an explicit quantity for the web channel. Fairer, and someone has to administer it.
• Computed availability. Stock minus reservations minus committed. The most correct, and the most dependent on the ERP being accurately maintained — which is where it usually breaks.

This decision doesn't belong to the technical team. It belongs to the business, and it's better made explicitly than discovered on the first day of a sale.

Decision 4 — What happens when something fails

Because it will: the ERP goes down, an API changes, an order arrives for a product discontinued two hours ago.

The non-negotiable minimum:

• Retries with increasing backoff. A network blip should never lose an order.
• Idempotency. If the same order arrives twice, it must be created once. Solved with a unique key from the source; skipping it produces the classic "the customer was invoiced twice."
• A visible failure queue. What doesn't land after N attempts goes to a screen someone looks at, not a log file nobody opens.
• Threshold alerting. Alert when 5% of orders fail, not on every individual error. An alarm that rings all day is an alarm that's been switched off.

The most expensive mistake

It isn't technical. It's integrating before cleaning.

If the storefront's products don't carry the same code as the ERP's, the integration cannot work — and the whole project quietly turns into a data normalisation exercise nobody planned for. It happens every time.

Put it in the plan from the start: agree the shared identifier and clean the master records first, then connect. A project that acknowledges that stage takes six weeks. One that discovers it in week four takes five months.

How long it takes

An integration of this kind, with all four decisions settled, is four to eight weeks. Less if the codes already match; considerably more if catalogues have to be unified.

And a warning about off-the-shelf connectors: they solve 80% in a day and the remaining 20% never, because that 20% is precisely what your company does differently. They're perfect if your operation is standard. If you have customer-specific price lists, channel allocations or your own reservation rules, the connector will carry you further than you expect before leaving you stranded.

About to take one of these on? Tell us which systems you're running and we'll tell you where the real work sits in your case.