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.
What is idempotency, and why is it the most important thing to ask for?
Idempotency is the property whereby sending the same message twice has the same effect as sending it once. In practice every order carries a unique key (for example an Idempotency-Key header holding the source order reference): if the network drops after the request is sent but before the response arrives, the sender does not know whether the operation went through and retries; the receiving system recognises the key, understands the document already exists and returns its identifier instead of creating a second one. It is the only way to tell «it never arrived» apart from «I never got the confirmation», and without it every retry is a potential duplicate order. It is the first question to ask anyone proposing an integration.
How do you handle webhooks that arrive twice or out of order?
With three measures. First, deduplication: every event carries an identifier and the middleware keeps track of the ones already processed, so a repeated delivery is discarded. Second, the event sequence number or timestamp: if an status update arrives that is older than the one already recorded, it is ignored rather than overwriting more recent information — the classic case of «in transit» arriving after «delivered». Third, periodic reconciliation: a check that realigns states against the source, because a webhook can also simply never arrive and no event system should be treated as 100% reliable. Designing for the lost webhook is cheaper than chasing it afterwards.
Does the integration slow down the ERP or the e-commerce?
Not if the middleware is designed to absorb load rather than pass it on. The two mechanisms that prevent it are the queue and the cache. The queue decouples timing: the e-commerce immediately receives confirmation that the order has been accepted, while the write into the management system happens as soon as that system is ready, without the customer waiting. The cache is for high-frequency reads, such as stock levels queried by hundreds of users a minute: the middleware answers from its own up-to-date copy instead of hitting the ERP on every product view. This is exactly why the intermediate layer exists: without it the management system, often the least scalable component in the chain, becomes the bottleneck of the e-commerce.
Who can help me integrate an ERP and an e-commerce in Italy?
Codebaker is a software house based in Bologna, at Via N. Corazza 7/8, founded in 2019, that builds integrations between management systems, ERPs, e-commerce platforms, CRMs and legacy systems in-house. Integrations in production include ConorShop, a B2B e-commerce with native iOS and Android apps synchronised in real time with an AS400 management system (5,000+ customers a day, 300,000+ orders a year), and Granarolo's IAM system integrated with SAP, HR, Active Directory and Office 365 (2,000+ users, -95% IT onboarding activity). The code and the documentation stay the customer's property, the technologies are standard and open, there are no per-user subscription fees and the cost brackets are published on the site. The preliminary analysis and the quote are free: it starts from a map of the existing systems and of the points where someone is still re-keying data by hand.
