Ask a vendor whether their tool integrates with the rest of your stack and you will almost always get a yes. Press on what that yes means, and a surprising amount of the time it resolves to this: you can export your data as a CSV. There is a button. You click it, a file downloads, and the data is now technically out of the tool and available to do something with. The vendor calls this interoperability. It is not. It is the opposite of integration wearing integration's name.
The distinction sounds pedantic until it costs you a quarter. An export is a one-time photograph of the data at the instant you clicked. An integration is a living connection that stays current as the data changes. These are not two points on the same spectrum. They are different things, and confusing them is how teams end up building elaborate reporting machinery on top of data that was already stale the moment it landed.
Why an export is a photograph
When you export a CSV, you capture the state of the system at one moment and freeze it. The file does not know that three rows changed an hour later. It cannot. It is a dead snapshot the instant it is created, and from then on it diverges from the live source with every edit anyone makes upstream.
For some jobs a snapshot is fine. If you want a record of where things stood at quarter end, an export is exactly right. The trouble starts when a snapshot gets used as if it were a connection: when someone exports from four tools, joins the files in a spreadsheet, builds a dashboard on top, and calls it a single source of truth. What they have built is a single source of truth as of last Tuesday, slowly rotting, and the rot is invisible because the dashboard looks identical whether the data underneath is current or three weeks old. This is the mechanism behind the heroic spreadsheet that every scaling company eventually depends on and quietly dreads.
Why "we have an API" is not the same as "it integrates"
The more sophisticated version of the export claim is the API. An API is genuinely better than a CSV button, because it can be called repeatedly to keep data fresh. But having an API and being integrated are still different things, and the difference is the work nobody wants to own. An API is a capability. An integration is that capability actually built, maintained, and kept alive as both systems change their schemas, rate limits, and field meanings underneath you.
This is where integration debt accumulates. Every "we have an API" is a promissory note that someone, eventually, will write and maintain the code that turns the capability into a living connection. That someone is usually an internal team with other priorities, and the connection they build is brittle, because it has to reconcile concepts that do not line up cleanly across tools. The API made integration possible. It did not make it happen, and the gap between possible and happening is a standing engineering cost that grows every time a connected tool ships a change.
The deeper problem: connection without a model
Even a perfectly maintained live connection does not solve the real problem, which is that the data arriving from each tool describes a different slice of the world in a different vocabulary. Your project tool's "project," your finance tool's "cost centre," and your OKR tool's "initiative" are not the same object, so connecting them is not a matter of moving data but of reconciling concepts. Every tool lies a little, and a connection that faithfully transports each tool's local truth still leaves you holding several local truths that do not compose.
This is why integration, properly understood, is not plumbing between tools. It is feeding the tools' data into a model whose objects are the things that actually span them: goals, work, ownership, capacity. The connection is necessary and nowhere near sufficient. Without a model designed to hold the joins, a live integration just delivers fresh versions of the same incompatible shadows, faster.
What real integration looks like
Real integration has three properties an export does not. It is live, so it reflects the current state rather than a past one. It is maintained, so it survives the schema and field changes that both systems will inevitably make. And it lands in a model, so the data from each tool connects into a shared structure rather than piling up as parallel feeds that someone still has to reconcile by hand. This is what it means to connect tools without rebuilding them: the existing tools keep doing their jobs, and their outputs feed a layer where the joins finally have somewhere to live, rather than being reconstructed in a spreadsheet every time someone asks a question. You can see the shape of this in how Vindaris treats integrations as the substrate that makes the stack consistent, not as a one-time data dump.
What to do this quarter
Audit what your vendors mean when they say they integrate. For each tool you depend on, ask three questions. Is the connection live, or is it an export someone runs manually? Is it maintained by someone whose job it is, or is it brittle code one engineer wrote and forgot? And does the data land in a model that holds the joins, or does it pile into a spreadsheet that a human reconciles? Most "integrations" in a typical stack fail at least two of these. Knowing which ones fail, and where the manual reconciliation actually happens, tells you exactly where your single source of truth is quietly a single source of last-Tuesday.
FAQ
What's the difference between an export and an integration? An export is a one-time snapshot of data frozen at the moment you click, diverging from reality with every upstream edit afterward. An integration is a live connection that stays current as the data changes. They are different things, not two points on a spectrum, and using a snapshot as if it were a connection is how dashboards end up confidently displaying stale data.
Isn't an API the same as an integration? No. An API is a capability; an integration is that capability actually built and maintained as both systems change underneath you. The gap between "we have an API" and "it is integrated" is ongoing engineering work that someone has to own, which is where integration debt accumulates.
If a connection is live, is that enough? Not by itself. Even a perfectly maintained live connection delivers each tool's data in its own incompatible vocabulary. Real integration feeds that data into a model whose objects span the tools, because every tool describes a different slice and those slices do not compose on their own.
How do I evaluate a vendor's integration claim? Ask whether the connection is live or a manual export, whether it is maintained by someone accountable or is brittle forgotten code, and whether the data lands in a model that holds the joins or piles into a spreadsheet. Most stack integrations fail at least two of these tests.