Your ERP is not being replaced — finance has settled that. What no website quote settles is how the new website and the old system will exchange orders, stock and prices. There are three real routes: connect directly through an API, put a middleware layer between the two, or exchange files on a schedule. The right choice depends on how fresh the data must be, and what your ERP actually exposes.
The short answer: decide by data freshness and what your ERP actually exposes
If your ERP offers a documented, supported API and the website needs near-real-time stock or order status, connect directly. If several systems must exchange data, or the ERP's interface is limited, put middleware in the middle. If data changes slowly and a delay of hours is harmless, scheduled file sync does the job at the lowest build and running cost. Decide per flow, not per project: orders may justify an API while prices ride happily on a nightly file.
The problem: the integration question every website quote dodges
Website proposals routinely contain a line like "ERP integration included" with no method, data flow or owner. The question is dodged because it is hard to price before anyone has examined the ERP. Deferred, it surfaces mid-build in its most expensive form: orders re-keyed by hand from email notifications, stock typed in from warehouse printouts, prices drifting until a customer is quoted the wrong figure.
Choose the method explicitly, per data flow, before re-quoting.
First, audit what you have: does your ERP expose an API, a database, or only files?
Before comparing routes, establish what your ERP — vendor, version, licence — actually offers. Capabilities differ by version, so work from the vendor's official documentation and your support partner's answer.
Ask four questions. One: is there a documented API, licensed and supported on your version — or an undocumented interface a previous developer found? Two: may you read the database directly? Many vendors permit read-only views but forbid writes that bypass their business logic. Three: what file exchange is built in — scheduled exports and imports of files such as CSV or XML, in which fields? Four: who administers the ERP today, and can they create the accounts, views or export jobs each route needs?
The answers sort most firms quickly: a supported API opens Route 1, database reads or a wrapper allow a hybrid, files alone point to Route 3.
Route 1 — direct API: when it's available, what it costs in discipline
Direct connection means the website talks to the ERP's own API: an order placed online is created in the ERP within seconds, and a stock query returns the ERP's current figure. It is the only route that supports genuinely live promises: real-time availability and instant order confirmation with an ERP order number.
The website now depends on the ERP's availability and response times, so timeouts and graceful failure must be designed, not hoped for. When the ERP is upgraded, the integration is retested. A supported API on paper is not always complete — check that the exact objects you need (orders, stock by warehouse, price lists, invoice status) are exposed, and writable where you need writes.
Route 2 — middleware: a translation layer when systems can't talk directly
Middleware is a layer — an integration platform or a purpose-built service — that sits between website and ERP, receives data from each, translates formats, field names and codes, and delivers it to the other. Choose it when the ERP's interface is limited, when formats need real transformation, or when more systems are coming: the same layer can later carry CRM, courier or accounting connections, each connecting once to the middle.
The trade-off is a component to host, license or build — one that concentrates fragility in a single monitored place rather than scattering it across point-to-point scripts, but needs a named owner.
Route 3 — scheduled file sync: the unfashionable option that is often enough
Scheduled sync exchanges structured files at set times: the ERP exports stock and prices nightly (or hourly) for the website to import, and the website exports the day's orders in a file the ERP imports. No live connection exists, which is its strength: each side runs independently, a failed file can be re-sent, and every exchange is an inspectable artefact.
It is enough whenever the business can tolerate the interval. Stock that moves a few times a day, prices that change weekly, orders picked in batches — none needs a live link, and pretending otherwise buys complexity without accuracy. Its limits are clear: the website shows stock as of the last sync, so high-demand items can oversell between runs, and order confirmations cannot carry live ERP references.
Head-to-head table: freshness, build effort, fragility, running cost, who maintains it
| Factor | Direct API | Middleware | Scheduled file sync |
|---|---|---|---|
| Data freshness | Seconds; genuinely live | Minutes; near real-time | The sync interval: hourly to nightly |
| Build effort | Moderate, if the API is complete and supported | Highest: a layer to build or configure, then both connections | Lowest: export and import jobs |
| Fragility | Tied to ERP availability and API version changes | Concentrated in one monitored layer; queues absorb outages | Lowest coupling; failures are visible files |
| Running cost | Low to moderate: monitoring, retesting on ERP upgrades | Highest: platform licence or hosting, plus ownership | Lowest: scheduled jobs and reconciliation time |
| Who maintains it | Website developer with ERP partner support | A named integration owner — internal or partner | Operations/IT at each end, simple runbook |
No row wins every column: match each flow to the row whose weaknesses you can live with. The storefront half has its own scope — see our ecommerce development work.
The flows that matter: orders in, stock and prices out, invoices and status back
Orders in (website → ERP) decides the route for most firms. Every order needs a unique reference both systems share, a rule for ERP rejections, and a same-day exception report — an order that never reached the ERP is revenue dropped.
Stock and prices out (ERP → website) must carry one master: the ERP. The website should never become a second place where prices are edited.
Invoices and status back (ERP → website) closes the loop: dispatch status, tracking references and invoice copies let customers self-serve. This flow also matters for UAE e-invoicing: under Ministerial Decisions 243 and 244 of 2025, e-invoicing through an Accredited Service Provider is being phased in, so design the integration to extract invoice data cleanly from the ERP.
Failure handling: monitoring, retries, reconciliation — decide before go-live
Integrations fail quietly or loudly; choose loudly. Every route needs four agreements. Monitoring: each exchange is logged with record counts, and a named person is alerted on failure. Retries: failed records queue and retry automatically where safe, never silently discarded. Reconciliation: control totals (orders sent versus received, stock value before and after) are compared on a schedule. Ownership: one person owns the integration, with a runbook a second person can follow.
Decision criteria and a phased path (start with sync, earn the API)
Apply three tests per flow. Freshness: what breaks if this data is an hour old, or a day old? Exposure: what does the ERP offer for this object — API, database, files? Consequence: what does one lost or wrong record cost?
Phase the build. Start with scheduled sync for stock and prices — cheap, visible, live within the first release — and put orders on the best route the audit supports. Live stock is earned later, when volumes prove the route is the constraint. Phasing protects the launch: the site ships on the sync it can rely on, as in our Dubai ecommerce development work.
Common mistakes
Assuming the ERP has an API because the version's brochure shows one, without checking your version and licence. Letting the website become a second master for prices or stock. Scoping "integration" as one line with no flows, directions or owners named. Testing only the happy path. And launching without reconciliation, so the symptom of a broken sync is an angry customer, not an alert.
FAQ
Our ERP has no API. Can a website still connect to it?
Yes, in most cases: a scheduled file exchange (the ERP exports and imports files such as CSV or XML), read-only database views where the vendor permits database access, or a small API wrapper built in front of the system. Which applies depends on your ERP and version — confirm in the vendor's official documentation.
Is scheduled file sync reliable enough for stock and prices?
For many firms, yes. If stock changes a few times a day and orders are picked from the warehouse rather than reserved instantly online, an hourly or nightly sync with control totals and daily reconciliation is dependable. It fails only where the website promises live availability.
What does middleware actually do, in plain terms?
Middleware sits between the website and the ERP and translates: it converts one system's fields and codes into the other's, queues anything that fails, retries it and logs every exchange. One translation layer — worthwhile when several systems connect, overkill for one simple link.
Which system should own which data?
Agree one master per record type before anything is built. Typically the ERP owns products, stock, prices and invoices, because finance already trusts it; the website owns the web account and the order as placed, then hands it to the ERP. Every shared field needs a named owner and a conflict rule.
Should we replace the ERP instead of integrating with it?
A separate, larger decision, and this article assumes finance has decided the current system stays. Integrate when the ERP still runs the business well and only the customer-facing side needs to change; if the ERP itself is failing operations, save the money towards replacement.
Map the integration before you re-quote the website (CTA)
If your website quotes keep stalling on the integration line, get the method decided first: audit what your ERP exposes, choose a route per flow, and scope the failure handling. That mapping is where our custom web application development work starts, with an itemised proposal within 24 business hours once the scope is agreed. See our pricing, or contact us with your ERP name, version and the flows you need — we will tell you plainly which route fits, including when the answer is the cheapest one.
