API Data Integration: When Connected Isn't Integrated

Almost every article about API data integration is a definition. What an API is, what integration is, why businesses need both. IBM has one. OpenText has one. Postman, Cleo, Tray and a dozen others have one. They are all broadly correct and none of them describe the situation most operators are actually in.

That situation is this: the systems are already connected. Data moves between them on schedule. And the numbers still don't agree.

Connection is plumbing. Integration is agreement.

An API connection moves a record from one system to another. It says nothing about whether the two systems mean the same thing by that record.

This is the part that gets skipped, and it is where the money goes. Consider a colour-coded planning spreadsheet we encountered in a delivery operation, where blue meant two entirely different things depending on which column it appeared in — the team assigned to a job in one place, the geographic zone in another. A human maintaining that sheet knew which was which. Any pipeline reading it faithfully would produce clean, well-formed, confidently wrong data.

That is not an edge case. It is the normal condition of a business that grew faster than its tooling. Every system in it encodes assumptions that were obvious to whoever built it and are invisible to everyone else.

So the useful question is not "are these systems connected." It is: when these two systems disagree, which one is right, and who decided?

If nobody can answer that, adding an API will move the disagreement around faster.

The four failure modes

1. The same word means different things.
"Client" is the classic. In one delivery operation there were two distinct parties — the business sending the order, and the person receiving it at the other end. Both were called the client, both needed to be notified, and a system modelling only one of them silently loses half the picture. Most integration specs discover this in testing.

2. The record exists in two places with two owners.
Both systems allow edits. Neither is designated as authoritative. The pipeline runs in one direction and quietly overwrites, or runs both ways and produces a conflict nobody sees. This is the most common cause of "the data was fine last week."

3. The meaning lives outside the data.
The handwritten comment on a signed delivery note. The free-text instruction that says "call before delivery." The margin annotation on a bid document. This is where the operational truth of a transaction usually sits, and a standard API integration carries none of it — it moves the structured fields and drops the meaning. This is precisely where AI changes the calculation, because reading and classifying that unstructured content is now tractable.

4. Nobody validates on arrival.
Data crosses cleanly, is malformed or contradictory, and is discovered three weeks later by a person doing something else. In one procurement operation, systematic validation of incoming supplier pricing against what was actually requested cut pricing discrepancies by 90% and pricing errors by 70%. Those errors were being caught by humans before, or not at all. (Full case study)

What actually fixes it

Designate the source of truth per entity, not per system.
Not "the CRM is authoritative." Rather: the CRM owns contact details, the ops platform owns delivery status, finance owns invoice state. Write it down. Most teams have never made this explicit, and the argument that surfaces when they try is the real integration project.

Reconcile vocabulary before you build pipes.
List every entity that appears in more than one system and have each owner define it in a sentence. The ones where the definitions differ are your actual work. This exercise takes a couple of days and routinely saves months.

Split ambiguous fields.
Where one field carries two meanings, it becomes two fields. The delivery operation's "blue" became an assigned-team field and a geographic-zone field, and a class of error disappeared with it. Unglamorous, permanent.

Validate at the boundary, not downstream.
Check on arrival, flag on arrival. The cost of a bad record rises steeply with how long it sits unnoticed.

Capture the unstructured layer deliberately.
If the real information is in a photograph, a handwritten note or a free-text field, decide explicitly whether to extract it. Extraction is the cheapest and most checkable kind of AI work — a human compares the extracted fields against the source in seconds. What you get is data that never existed before, rather than a faster copy of data you already had.

When integration is the wrong shape entirely

There is a point past which more pipes stop helping, and it arrives earlier than most teams expect.

The test we use elsewhere is whether to automate, integrate or build — worth reading, because those three are routinely mis-sold as each other and have very different costs. What that framing doesn't cover is the specific warning sign for this decision, which is re-keying.

Count how many times a single record is typed by a human between arriving and being finished. If the answer is once, integration will help you. If the answer is four, the systems aren't the problem — the absence of a shared record is, and connecting them preserves that absence in a more expensive form. One delivery operation was spending ten minutes building each order because the same facts were entered into four places; a perfect set of APIs between those four would have produced a faster, better-synchronised version of exactly the same waste.

The second warning sign is who gets asked. If the answer to "what's the status" is always a person rather than a system, no pipeline fixes that, because the thing being asked for doesn't exist anywhere yet.

What integrated data is actually worth

The reason to do this properly is not tidiness. It's that reconciled data is the precondition for anything intelligent sitting on top.

Bringing fragmented marketing, business and financial inputs into a single structured intelligence layer is what made causal attribution modelling possible for one client — pushing analysis that had taken four days down to seconds, at roughly 50% higher accuracy than correlation-based approaches. (Full case study)

That result is not an artefact of the model. It is an artefact of the inputs finally agreeing with each other. No amount of model quality compensates for two systems that disagree about what a customer is.

Connection is the cheap part. Agreement is the work.

If you're not sure which of the two you're missing, that's the conversation to have first.