How do you connect an eShop to ERP or XML? A practical guide to products, stock and orders

What does “connecting an eShop to ERP” actually mean?

It is a controlled data flow between the online store and a commercial or accounting system. One flow may publish products, prices and availability to the store; another may send new orders to ERP; a third may return a document number or shipment status. It is not necessarily one bridge that does everything.

A dependable solution is divided into smaller flows, each with its own trigger, data, permissions, cadence and failure behavior. A temporary product-feed issue should not have to stop order export, and retrying one failed order should not create a duplicate ERP record.

ERP, API and XML are not the same thing.

ERP is the operational system in which a business may manage products, inventory, customers, orders and accounting documents. An API is an agreed interface through which applications request or send data. XML is a data representation format; it can be delivered as a file or feed, but it does not define when imports run, how fields are mapped or how errors are handled.

A supplier may offer a product XML feed without an order API. An ERP may expose an API, a scheduled export or a connector limited to a particular version. Technical discovery begins with what is genuinely available rather than assuming every vendor supports the same method.

Every field needs one primary data source.

If a price can be changed in ERP and eShop without a priority rule, the next update may undo a correct change. The same applies to stock, titles, descriptions, tax, categories and images. The team decides where each datum is maintained and which system is allowed to update it.

A common pattern keeps item code, price and accounting stock in ERP while the eShop owns commercial titles, descriptions, SEO fields, categories and media. That is not a universal rule; it is one possible architecture that must match the business operation.

SKU, barcode and GTIN provide the matching foundation.

A product name is not a safe identifier. It can change, be translated or be reused across variations. Each trade item needs a stable code and a clear relationship between the internal item code, store SKU, barcode or GTIN and supplier identifier.

GS1 notes that unique identification and communication of changes between trading partners are essential to correct product presentation and fulfilment in eCommerce. Before bulk import, the process audits duplicate codes, missing IDs, variations and identifier changes.

Product mapping is a business rule, not a field-copying exercise.

A feed may call a category “Living room”, the store may use “Home furniture” and ERP may represent the same group with a numeric code. Mapping is required for categories, attributes, units, tax, weight, dimensions, brand, images and variations. The process also defines what happens when a required field is absent or invalid.

A safe importer does not automatically publish every incomplete record. It may keep new items in draft, reject unsafe rows or route exceptions for review. That protects catalogue quality, SEO and the buying experience.

Pricing and stock need an explicit cadence and safety rules.

Real time is not always necessary or available. A fast-moving store with scarce inventory may require more frequent updates than a made-to-order catalogue. Cadence depends on volume, API limits, processing cost and commercial risk.

The design may include stock buffers, checks for zero or negative prices, tolerance for temporarily stale data and a defined response when the source is unavailable. A failed feed must not zero an entire catalogue or publish a price that failed validation.

Order export needs to be safely repeatable.

An order contains more than line items: customer, addresses, tax, discounts, shipping, payment and status. The business must decide when an order becomes ready for ERP — at creation, after payment or following human review.

Each export uses a stable identifier so a retry cannot create a second order. The result is stored with the ERP number or failure message. Returns, cancellations and partial fulfilment are designed separately because they are not simple reversals of the original flow.

One-way or two-way integration? Only what the operation genuinely needs.

Two-way editing increases the number of possible conflicts. If ERP sends stock and the store sends orders, those are two separate one-way flows — not necessarily full synchronisation of every field in both directions.

Start with the flows that remove the most manual error or resolve the largest operational problem. Additional directions can be enabled after data, logs and real operating experience are strong enough to support them.

Validation, logs, alerts and retries make an integration operable.

The useful question is not whether an error will ever occur, but whether it will be found quickly and understood. Logs identify the flow, record, time, result and an actionable message. They should not retain unnecessary personal data or access secrets.

Temporary failures can retry at a controlled rate. Permanent failures, such as an unknown tax code or malformed XML, stop the affected record and raise an alert. Endless blind retries load the systems and hide the underlying defect.

Security requires least privilege and controlled secrets.

API keys and credentials do not belong in public code or browser-downloadable files. Every account receives only the permissions it needs, connections use encryption where supported, and keys should be replaceable without rebuilding the complete solution.

When customer or order data moves, the business must define what is necessary, who can access it, how long logs are retained and how its obligations are handled. Technical delivery does not replace legal or accounting advice.

WooCommerce, OpenCart or custom commerce: the principle is shared, implementation differs.

WooCommerce provides a REST API for products, orders and other resources. OpenCart offers an extensible architecture, while the available integration route depends on version, extensions and existing custom code. A custom commerce system requires documentation or a technical audit of its endpoints and data model.

Firstidea builds integrations for WooCommerce, OpenCart and custom systems. Platform choice follows catalogue, operations, team and future change — not simply whether a connector exists. See also WooCommerce or OpenCart.

Testing must cover normal flows and intentional failures.

Before production, representative products cover simple items, variations, missing images, special tax, identifier changes and zero stock. Orders cover discounts, shipping, multiple payment methods, cancellation and safe retry.

Rollout is staged: a read-only check or limited sample first, then one flow, then the remaining flows. The release has a backup, rollback route, monitoring for the first cycles and a named decision owner for every exception.

What determines the time and cost of an integration?

Field count alone is not enough. Important factors include documentation quality, available interfaces, versions, licences, volume, variations, update directions, exceptions, historical data and the required monitoring level.

A responsible estimate begins with samples and technical answers from all parties. Firstidea’s ERP and XML integration service structures that work from inventory and mapping through testing, controlled rollout and support.

Checklist before requesting an estimate.

You do not need a finished technical specification. You do need the real environment and the main operational priorities.

• Exact ERP, eShop and critical-extension versions.
• Technical contact or authorised ERP partner.
• API documentation, sample XML/CSV or export description.
• Fields that need to move and intended direction.
• Representative products, variations, orders and exceptions.
• Required cadence and acceptable delay for each flow.
• Current manual steps, frequent errors and business impact.
• Logging, alerting, reporting and support requirements.

Where does this guide sit in Firstidea’s eCommerce silo?

The main eCommerce development hub explains the wider commerce system. The ERP and XML specialist page owns the commercial service and delivery process. This guide answers the technical and operational questions that come before a decision.

For customer-specific pricing, roles and order approval, see B2B eCommerce. For supplier-fed catalogues, see dropshipping eShop development. These pages connect because they share real data flows, not to manufacture an artificial web of links.

Frequently asked questions

Can any ERP be connected to an eShop?

Only when a technically safe exchange method exists, such as an API, connector or controlled file export. Version, licences and ERP-provider cooperation affect the feasible depth.

Does the integration need to be real time?

Not always. The right cadence depends on operational risk, volume, system limits and the acceptable delay for each flow.

Is API better than XML?

There is no universally better option. An API may support more interactive flows, while a well-defined XML feed is sufficient for many scheduled imports. Interface quality and stability matter most.

How are duplicate products prevented?

Stable IDs, explicit SKU/GTIN/supplier-code mapping, uniqueness constraints and checks before every create or update operation.

How are duplicate orders prevented?

Each order uses a stable external identifier, and retries check whether the ERP record already exists. The ERP result or record number is stored with the order.

Can descriptions remain in the eShop while prices come from ERP?

Yes, when that rule is explicit. Different fields commonly have different primary sources so commercial content is not overwritten during a price update.

What if a supplier changes its XML without warning?

The importer validates structure and required fields before writing. An incompatible change stops the affected flow and raises an actionable alert.

Can you take over a failing existing integration?

Yes, after reviewing code, scheduled jobs, logs, credentials, samples and real incidents to locate the issue across store, ERP, feed or infrastructure.

Is staging required?

For changes affecting catalogue, price, stock or orders, a representative safe environment materially reduces risk. Production rollout should still be staged and monitored.

Who maintains the integration after launch?

That responsibility must be agreed before release: who monitors logs, who owns the ERP response, who reviews commercial exceptions and who approves field or flow changes.