API integration between your ERP and online store, step by step

Your ERP holds the stock, the prices and the invoices. Your store holds the orders. Between them sits a person with two browser tabs and a spreadsheet. This article covers what it takes to remove that person from the loop.

Written from delivered integrations, not from vendor documentation. Timelines and costs are our own 2026 ranges, in euro.

What actually needs to move

Most people say “connect the ERP to the store” and mean four separate flows, each with its own direction and its own failure mode:

1. Catalogue — ERP to store
   • Products, prices, categories, attributes.
   • Usually daily. Rarely urgent.
2. Stock — ERP to store
   • The one everybody argues about. Covered in its own article.
   • Anywhere from live to every 15 minutes.
3. Orders — store to ERP
   • The flow that must never lose a record.
4. Status — ERP to store
   • Invoiced, packed, shipped, tracking number.

The four have different tolerances. Catalogue can be a day stale and nobody notices. An order that vanishes costs you a customer and an argument.

The four integration patterns, and when each fits

Scheduled pull. A job runs every N minutes, asks the ERP what changed, writes it to the store. Simple, debuggable, replayable. It is the right answer far more often than people expect. Its weakness is latency: your worst case is the full interval.

Webhooks. The ERP calls you when something happens. Low latency, but you inherit every delivery problem: retries, duplicates, out-of-order events, and the webhook that fires while your server is redeploying. Never treat a webhook as the only copy of the truth — pair it with a periodic reconciliation pass.

Direct database read. Sometimes the only option with an old ERP that has no API. It works, and it is fragile: a vendor update changes a column and your integration breaks silently. If you must do it, read from a view you control, never from the vendor’s tables directly.

Middleware queue. Both systems talk to a queue in the middle. More moving parts, but each side can be down without losing data, and you get a replay log for free. Worth it above roughly 500 orders a day, or when a third system joins.

Building it: the order of work

Step 1. Agree the join key. Every integration lives or dies on one question: what identifies a product in both systems? Usually SKU. Sometimes an internal ERP code that nobody typed into the store. Settle this before writing any code — retrofitting a join key across 4,000 products is a week you will not enjoy.

Step 2. Build the mapping layer. ERP statuses are not store statuses. ERP VAT codes are not store tax classes. Put the translation in one place, in configuration, not scattered through the code. It will change.

Step 3. Make every write idempotent. The same order will arrive twice. A retry will fire after a timeout that actually succeeded. Every operation needs to be safe to repeat: check for an existing record by external ID before creating one.

Step 4. Add the error queue before you need it. Failed records go to a queue with the payload and the error, not to a log line nobody reads. Someone must be able to fix the cause and replay the batch.

Step 5. Reconcile on a schedule. Once a night, compare counts and a checksum of the day’s orders on both sides. Drift is normal; undetected drift is how you find out in March that January was wrong.

What breaks, and how to not be woken at 2am

Stock races. Two customers buy the last unit within the same sync window. Decide the rule up front: reserve at checkout, or oversell and apologise. There is no third option, and the business must choose, not the developer.

Rate limits. The ERP tolerates 60 requests a minute; your catalogue has 8,000 products. Batch, and back off exponentially on 429s. A full catalogue push that hammers the ERP during business hours is how you get your integration switched off.

Partial fulfilment. The order has five lines, the warehouse ships three. If your model assumes one order equals one shipment, this is a rewrite, not a patch. Model it correctly from the start even if the client says it never happens.

Silent success. The worst failure mode is a job that returns 200 and writes nothing. Alert on absence: if fewer than X orders synced in the last hour during business hours, something is wrong.

What it costs and how long it takes

Real ranges for 2026, for companies with 10–200 employees:

• One-way catalogue and stock sync, standard ERP with a documented API: 3–5 weeks.
• Two-way orders and statuses on top of that: 4–8 weeks total.
• Old ERP with no API, database or file-based: add 2–4 weeks and a maintenance agreement — this one needs watching.
• Queue-based middleware with a third system: 8–12 weeks, delivered in stages.

The estimate arrives after we read your ERP’s API documentation and pull one real order through by hand. Anyone quoting an integration price before seeing the ERP is guessing.

How to know it worked

Measure before you start: hours per week spent retyping between systems, orders entered wrong per month, hours from order placed to invoice issued.

• Realistic target: 95% of orders reach the ERP without a human touching them;
• Typical payback: 4–9 months for a standard two-way integration;
• Success signal: the person who used to run the two browser tabs is doing something else entirely.