Connecting the tools you already use: a guide to integration

Data silos cost the average company $12.9 million annually in lost opportunity and wasted effort, and fragmented data can consume up to 30% of annual revenue according to IDC estimates. Every growing company reaches the same point: it has the right tools for each job, and now those tools do not talk to each other. Customer records in the CRM, orders in the e-commerce platform, invoices in the accounting system, shipments in the logistics portal. Each system is doing its job. But the company is paying people to move data between them, and that work creates no value.

Why systems don't talk to each other by default

Software vendors build products that solve specific problems well. They have no incentive to make it easy to route around their system, and deep interoperability requires standardisation the market has only partially achieved. The result is a landscape of capable tools with incompatible data models, different authentication mechanisms, and API rate limits. Employees waste 8 to 10 hours per week on manual data reconciliation between systems, and a single staff member spending 30 minutes daily re-entering data loses over 125 hours of productive work per year.

Many systems businesses rely on were not designed for integration. Older ERPs, legacy CRMs, and custom-built internal tools may only expose data through file exports, database views, or manual entry screens. Integration with these systems is possible but requires a different approach than connecting two modern API-first platforms.

Three integration patterns worth knowing

Most integration problems map to one of three patterns. Understanding which fits your situation determines how much complexity you are taking on:

• Point-to-point: a direct connection between two systems. Simple with two systems but creates a web of dependencies difficult to maintain with five or more.
• Hub-and-spoke: a central integration layer every system connects to. Greater upfront investment but easier to add new systems and diagnose problems from one place.
• Event-driven: systems publish events when something happens, subscribers react. Loose coupling and scalability, but requires careful design around ordering and failure handling.

For most companies integrating five or fewer systems, a hub-and-spoke approach with a clear central data model gives the best balance of control and simplicity. Event-driven architecture pays off at high volume and when real-time reactions are required, but introduces operational complexity worth the cost only at significant scale. Only 2% of organisations have currently integrated more than half their applications, which shows how much optimisation most companies still have ahead of them.

Start at the data boundary, not the API docs

The most common integration mistake is starting with the API. You read the documentation, map endpoints to your needs, and start building. Three weeks later you discover the field you need is only available on a higher subscription tier, updates with a 15-minute delay, or the webhook you counted on is unreliable under load. The system's data model has shaped the integration in ways you did not plan.

A better starting point is the data itself: what is the canonical record, who manages it, and how often it changes. Design the data flow first. Decide where each piece of information lives and which system is authoritative when two have conflicting versions of the same fact. Then map that design onto the available APIs. This order does not eliminate surprises but reduces the number of architectural rethinks caused by limitations discovered late.

How integrations break, and how to catch it early

Integrations are uniquely fragile because they depend on contracts between systems that neither side fully controls. An API version deprecated. A field renamed without notice. A rate limit tightened. An authentication token expires and no one is notified. Each of these breaks the integration silently, and silent failures can compound for days before anyone notices an order was not fulfilled.

The answer is observability built in from the start: log every integration event with enough context to replay it, alert on failure rates rather than just individual incidents, and build health checks that verify end-to-end correctness rather than just connection availability. An integration that passes a connection test but has been silently dropping records for 48 hours is not healthy. Monitor for the outcome you actually care about.