How do I integrate my management system, e-commerce and other software through custom APIs?
You integrate them by building a layer of custom APIs — a middleware — that acts as the meeting point between the systems instead of wiring them together in pairs. The path has five moves: first, decide for each entity (customer, item, price list, stock, order) which system holds the truth, so there are never two versions of the same data; second, write the data contract, meaning which fields travel, in which format and under which validation rules; third, develop the middleware that exposes REST or GraphQL APIs, normalises the formats and propagates events via webhooks; fourth, choose for each flow whether real time is genuinely needed or a periodic batch is enough; fifth, add queues, retries, idempotency and logs, because a serious integration is not one that works, it is one that notices when it stops working. The typical result is the chain e-commerce → API middleware → management system/ERP → warehouse → courier, with a single piece of data travelling through every system without anyone retyping it.
Which data is typically exchanged between an e-commerce and a management system?
There are six recurring entities. From the management system towards the e-commerce travel customer master data with credit limits and terms, the item catalogue with descriptions and attributes, price lists (often customer-specific in B2B) and warehouse stock. From the e-commerce towards the management system travel the orders and, downstream, delivery notes and invoices come back for the customer to consult. The sixth entity is the delivery status, which arrives from the courier and must be visible both in the management system and in the customer's private area. In B2B, stock levels and customer-specific price lists are usually the flows that genuinely require real time, because a wrong price or an out-of-date availability generates an order that has to be cancelled.
My management system is old and has no APIs: can it still be integrated?
Yes, and it is one of the cases we handle most often. When the management system exposes no modern APIs, we build a dedicated integration layer that talks to it in the ways it does support — direct data access, native procedures, structured files, services exposed by the middleware — and translates all of it outward into clean REST APIs. The management system is neither modified nor replaced: it keeps working exactly as before, while the rest of the world talks to the layer. That is precisely what we did at Conor, where a B2B e-commerce with native iOS and Android apps and a web version synchronises in real time with an AS400 system, handling more than 300,000 orders a year and 5,000 customers a day.
Custom APIs, standard connectors or file exchange: which is better?
It depends on how standard your flows are. File exchange (CSV or EDI over FTP) is cheap and still holds up well for batch flows towards external partners, but gives you neither real time nor fine-grained error handling. Standard connectors and iPaaS platforms work well when both systems are widely used products and the fields line up, but they become expensive and brittle as soon as unusual transformations are needed; they also introduce a subscription and a dependency on the platform vendor. Custom APIs have a higher initial cost, but they cover any business rule, remain your property and are the only route when one of the systems is legacy or when the integration logic is itself part of your competitive advantage. In practice many companies use a mix: custom APIs for the critical flows, batch files for the marginal ones.
Do I really need real-time synchronisation on all data?
No, and demanding it is one of the most common ways to inflate the cost of an integration with no benefit. Real time is needed where stale data produces an immediate commercial error: stock levels, customer-specific price lists, credit limits, order status. For full master data, history, statistics and accounting reconciliation, a periodic alignment is more than enough, and it is also more robust because it tolerates a system being temporarily unavailable. The rule of thumb we apply is: real time on whatever blocks a sale, batch on everything else.
How much does it cost to integrate an ERP and an e-commerce via APIs?
A bounded integration on a few flows towards a system that already exposes documented APIs typically falls in the €5,000-15,000 band; a complete integration layer between e-commerce, management system, warehouse and couriers, with error handling and reconciliation, falls in the €15,000-50,000 band; architectures spanning several systems, several sites or high volumes go beyond €50,000. The variable that moves the price most is not the number of entities but the quality of the available interfaces: connecting to an ERP with documented REST APIs costs a fraction of building a layer towards a system that has none.
Which mistakes make an integration project fail?
Five, in our experience. First: not deciding which system holds the truth for each entity, and ending up with two customer records that drift apart. Second: treating integration as the last task of the project rather than an architectural requirement, only to discover at acceptance testing that an indispensable field does not exist. Third: ignoring the edge cases — partial orders, returns, changes after confirmation, blocked customers — which are the majority of the real work. Fourth: providing no error handling, retries or idempotency, so a lost webhook becomes a lost order and nobody notices for days. Fifth: not monitoring the flows in production, which is like having a fire alarm with no siren.
How do you stop an order from being lost or duplicated?
With three standard mechanisms we design in from the start. Idempotency: every message carries a unique identifier, so if it is sent twice the receiving system recognises it and does not create a second order. Queues with retries: if the management system is momentarily unreachable, the message is not discarded but retried at increasing intervals until it succeeds. Reconciliation: a periodic check compares totals across systems and flags discrepancies. On top of these sits monitoring with alerting, because an interrupted flow must be discovered by the system, not by the customer phoning in.
Who owns the APIs you develop?
The client. The integration layer, the code and the documentation belong to the company, built on standard, open technologies. This is a substantial difference from subscription connectors: if tomorrow you change e-commerce platform or want to connect a second sales channel, the middleware is already there and it is yours, and the APIs talking to the management system do not have to be rebuilt. It is also why an integration investment, done well, amortises across the next project instead of starting from zero.
