System integration: connecting ERP, CRM and business applications through APIs

Start from the business flows

Integration projects that start from technology tend to connect everything to everything. It is more useful to start from the business flows:

• Lead to order: from the first contact in the CRM to the confirmed order in the ERP.
• Order to cash: order, delivery, invoice, payment, reconciliation.
• Procure to pay: purchase request, order to supplier, goods receipt, supplier invoice.
• Master data: customers, suppliers, products, prices — created once, used everywhere.

For each flow, map which system holds which step, where data is retyped today, and where errors and delays come from. This map tells you which integrations matter and in which order.

Decide who owns each piece of data

The most important integration decision is not technical. For each data entity, decide which system is the system of record — the one place where it is created and changed:

• customers might be created in the CRM and pushed to the ERP when they place their first order;
• products and prices are usually owned by the ERP;
• credit limits by the ERP or the finance system.

Other systems read or receive copies; they do not edit them. When two systems can both edit the same record, they will eventually disagree, and no integration technology fixes that.

Integration patterns

Point-to-point

Each system connects directly to the others it needs. It is quick for the first two or three connections and becomes unmanageable as their number grows: every change in one system ripples through connections nobody documented.

APIs as the contract

A well-designed API exposes a system's capabilities — "create an order", "get a customer's open invoices" — as a stable, documented contract, independent of the internal database. Modern ERPs and CRMs provide APIs; for older systems, a small service in front of them can provide one. Good practice includes:

• a published specification, for example in OpenAPI format;
• versioning, so that changes do not break existing consumers;
• authentication and authorisation per consumer;
• limits on request rates to protect the underlying system.

Events

Instead of systems asking each other repeatedly whether something changed, the owner of the data publishes an event — "order confirmed", "customer updated" — and interested systems react. Events decouple systems in time: if the receiver is down, the message waits in a queue or broker until it comes back.

Integration platforms

As the number of flows grows, an integration platform — an iPaaS or an open-source integration framework — centralises connectors, transformations, monitoring and retries. It is not mandatory, and for a handful of flows it may be more than you need; but it helps keep integrations visible and maintained.

Designing for failure

Integrations fail: a system is down for maintenance, a network call times out, a record is rejected because a field is missing. Reliable integrations are designed for this from the start:

• Idempotency: processing the same message twice must not create two orders. Each message carries a unique identifier, and the receiver ignores duplicates.
• Retries with back-off for temporary errors, and a separate queue for messages that keep failing, so they can be inspected and replayed.
• Validation at the boundary, with clear error messages that a business user can act on.
• Monitoring of business outcomes, not just technical uptime: "orders received but not yet in the ERP after ten minutes" is a more useful alert than "service healthy".

Integration as a foundation for data and AI

Clean, documented flows between systems are also the foundation for reporting and automation. A data platform depends on reliable extraction from source systems, and AI agents that process documents are only useful if they can write their results into the ERP through a proper interface. Integration is rarely the visible part of a project, but it is what makes the visible parts work.

Where to start

Pick one business flow where retyping or reconciliation costs the most, define the system of record for each entity involved, and build that integration with proper error handling and monitoring. Our software engineering service designs and builds integrations as products in their own right — documented, tested and monitored.