Ecommerce ERP Integration Cost: Connector, Middleware, API

What actually drives the cost of connecting an ERP to an online store

An ERP-to-store integration usually moves six object types: products, prices, stock, customers, orders and invoices. Ecommerce ERP integration cost follows that list, the quality of the data behind it, and the number of states the business needs to see. The protocol matters least. REST, SOAP, webhooks with HMAC signatures, a scheduled file drop: all of them move a record. The money goes into deciding which system leads for each object, what happens when a message fails, and who reads the error queue tomorrow morning.

A second driver sits in the rhythm gap. An ERP posts in batches on a schedule; a shop creates records the second a customer clicks. Most defects in these projects are born in that gap, and each one costs more to fix after go-live than to design before it.

Three delivery models: prebuilt connector, middleware, custom API

A prebuilt connector is the cheapest start and the cheapest to run, as long as your document types are standard and the vendor keeps it current with your ERP's releases. It fails quietly the moment a process needs a field the connector does not carry, because that gap turns into manual work which never appears in the project budget.

Middleware, sometimes sold as an integration platform, holds the mapping, the queue and the retries outside both systems. It pays off from the third system onward - shop, ERP, warehouse, accounting, marketplace - or when you expect to replace one of them. It also adds a platform you have to run, monitor and pay for every month.

A custom API integration costs the most to build and the least to bend. It is the right answer when the process itself is your advantage: B2B pricing rules, configurable products, split deliveries, self-billing, multi-company invoicing. We build it when a standard path would force you to redesign how you sell.

A five-question test before you pick a model

Five questions settle the choice between a prebuilt connector, middleware and a custom API. Does a maintained connector exist for your exact ERP version and shop platform? How many document types fall outside the standard template? How many systems, not two, will eventually touch the same order? Who owns the integration after go-live, by name? And what happens to the business on the day the sync is down for four hours?

If the honest answer to the last question is "nothing, we phone each other", buy the connector. If it is "orders stop", you are buying error handling rather than a transfer, and the model has to reflect that.

Where the budget quietly overruns: master data, order states, returns

The founder of Primessio has led delivery teams of 5 to 75 people across 20+ years of IT projects, and one pattern repeats: the surprise is never the API, it is the data underneath. Tax IDs captured as free text in a B2B checkout. Three product identifiers for the same article. Order states that exist in the warehouse but not in the shop.

Returns and corrections are the other reliable overrun. A return touches stock, the customer record, the invoice and the payment, and in most shops it is modelled last. Map it first and it becomes a path you designed; map it last and it becomes a support queue.

What the transfer never solves: errors, retries and the audit trail

Idempotency, retries with backoff, a dead-letter queue, an operator view of what is stuck, and an audit log that shows which record moved in which direction and when. That list is the difference between an integration and a prototype, and it is the part a connector comparison sheet never covers. Without idempotency across the whole chain you get duplicate documents that nobody can unpick afterwards.

Invoicing deserves a line of its own. E-invoicing regimes put the invoice under a published schema and a state machine that lives outside your systems, so the shop should almost never talk to a tax gateway directly - the ERP stays the single source of truth for the document. We wrote that case up separately in our piece on KSeF 2.0 integration for ERP and online stores.

Judge it over two to three years, not by the starting price

Compare the three models over 2 to 3 years, not by the price of the first invoice. Count build or configuration, platform fees, the hours your team spends on manual workarounds, and the cost of the change you already know is coming. A cheap start with three manual steps per order is usually the expensive option by year two. We say so plainly when a project does not add up, because we are a software house that optimises instead of complicating.

How we scope the work, and where the experience comes from

Primessio's team has delivered 50+ IT rollouts across banking, telecoms, retail and public administration. Team experience includes a command system for Poland's State Fire Service used by 22,000 people, on a project budget of PLN 20.3 million, led by Primessio's founder. The sequence that experience taught us is unglamorous: measure the data quality on one real month of your documents first, then build the interface.

Primessio designed, built, deployed and maintains an operations system for a workforce and staffing company: a workflow engine with CRM and ATS, roles and permissions, and a full operations audit. In another project we built an HMAC-signed webhook that pushes each submission straight into a client's internal system in real time. Keeping systems like those alive in production is why our scoping for an ERP integration starts with failure paths rather than with a platform decision - we carry the maintenance of those decisions ourselves.

Dariusz Wtyklo, owner and CEO of Primessio, states the order on his own page: "I start with your process and the way you work: I put them in order, and only then choose or build technology made to measure." For an ERP and shop integration, that order is what keeps the model choice cheap.

Primessio works from the Warsaw area in Poland, a 1-2 hour flight from the DACH region, and keeps client data in the EU. Same-time-zone work matters more in integration projects than in any other kind, because every test needs both sides awake at once.

A 9-point scoping brief you can complete today

A 9-point scoping brief answers what any vendor needs before quoting an ERP integration. Write it on one page, before you talk to anyone. Which ERP, in which version, and which shop platform? Which objects must sync, and in which direction? Which system is the leading source for each of them? Which document types fall outside the standard template? What does your ERP actually expose as an interface today? How clean are the tax IDs, product identifiers and price lists? What must happen when a message fails, and who sees it? What does the customer see between order and invoice? And who decides on your side without a committee?

If you can answer all nine, you are ready to scope. If three or more are blank, those gaps are the project, and that is the honest starting point for a conversation.

Data, compliance and what we do not promise

We support your compliance work on the technical side: data in the EU, a data processing agreement under Article 28 GDPR, roles, permissions and logging. We do not provide legal or tax advice, and we make no guarantee of legal compliance for your specific case; e-invoicing obligations in particular must be checked against current national documentation and with your own advisor. We publish no rates, no savings percentages and no delivery dates before scoping, because none of them would be honest before we have seen your data. As of September 2026.

Frequently asked questions

How much does it cost to integrate an ERP with an online store?

There is no honest flat figure, and we publish no rates. Ecommerce ERP integration cost is set by variables you already control: how many objects sync (products, prices, stock, customers, orders, invoices, returns), how many document types break the standard template, how clean the master data is in the source system, and how much error handling, monitoring and audit logging the business needs. Two shops on the same platform can differ by a wide margin on the same ERP. We quote once the scope is clear enough to quote honestly.

Is a prebuilt connector cheaper than a custom integration?

At the start, almost always. Over two to three years, only if your processes stay inside what the connector supports. The cost people miss is the workaround: every field the connector cannot carry becomes a manual step, a spreadsheet or a nightly export that someone owns forever. If a maintained connector covers your document types and follows your ERP's release cycle, we recommend the connector, even though a custom build would be the bigger project for us.

What is middleware in an ERP ecommerce integration?

Middleware is a layer between the shop and the ERP that holds the field mapping, queues messages and retries what fails, so neither system has to know the other's data model. It earns its keep when more than two systems are involved - shop, ERP, warehouse, accounting, marketplace - or when you expect to swap one of them. It also adds a platform to run, monitor and pay for, so it is a poor fit for a single shop and a single ERP with six fields to move.

Which data should sync between an ERP and an online store?

Start with the minimum that keeps the business truthful: stock, prices, orders and customers, plus the invoice or delivery-note reference the customer will ask about. Then set direction and cadence per object: push or pull, event-driven or scheduled, one-way or bidirectional. Products and content often stay in the shop, master data stays in the ERP. Every extra object you sync is a mapping, a test case and a permanent maintenance line.

How long does an ERP ecommerce integration take?

We do not name a date before scoping, because the duration is set by clarification, not by coding. What moves the schedule: the number of objects and document types, the quality of the data in the legacy system, which interfaces your ERP actually exposes, and how fast your team can review and sign off. We work in short cycles so the first working flows go live early, and we commit to a date once those points are settled.

Do I still need a developer if my ERP already has a connector for my shop platform?

Often yes, but for a smaller job. The connector moves the standard path; someone still has to decide the leading system per object, map the fields the connector leaves empty, design what happens on a failed sync, and give the error queue a named owner. That is an afternoon of decisions and a few days of configuration in the good case, and a real project in the case of custom document types, multi-company setups or B2B pricing.

Related service: Software & IT systems →