Integration, so the same data is never typed twice.

An API is an interface a system exposes so other software can read or change its data. An integration is the working connection built between two or more systems, which usually consumes APIs but also has to handle ownership of data, direction of flow, failures, retries and monitoring. Having an API available is not the same as being integrated.

Usually, yes. Options include a direct but read-only database connection, a scheduled file exchange, the vendor’s import and export routines driven automatically, or in constrained cases robotic automation of the interface. These are less elegant and we say so, but they are frequently enough to remove the manual rekeying, and they can be replaced later if a real API appears.

Every transfer carries an idempotency key, so if a request is retried after a timeout the receiving system recognises it and does not create a second record. Combined with a dead-letter queue for anything that genuinely cannot be processed, that means a failure becomes a visible item to resolve rather than a duplicate or a gap.

Point to point is right for two or three connections and becomes unmanageable beyond that, because the number of links grows faster than the number of systems. Once you have four or more systems exchanging data, a thin integration layer costs less over five years and makes replacing any one application a contained piece of work.

A single well-built, monitored connection is typically a low five-figure piece of work; a programme joining four or five systems with a middleware layer is larger and is phased. The data-ownership mapping phase is small and fixed-price, and it is where most of the cost of getting it wrong is avoided.

We version against their API and monitor for schema and behaviour changes, so a change surfaces as an alert rather than as missing data. Because the integration is documented and the transport is shared, adapting to a vendor change is normally hours of work rather than a rebuild.

We version against their API and monitor for schema and behaviour changes, so it surfaces as an alert rather than as missing data discovered a week later. Because the integration is documented and the transport is shared across flows, adapting is usually hours of work rather than a rebuild.

They go to a dead-letter queue and raise an alert, rather than disappearing into a log nobody reads. There is an interface to inspect what failed and why, and to replay it once the cause is fixed. A failure becomes a visible item to resolve instead of a gap you find at month end.

Point to point is right for two or three connections and becomes unmanageable beyond that, because the number of links grows faster than the number of systems. Once four or more systems exchange data, a thin integration layer costs less over five years and makes replacing any one application a contained piece of work.

Less than people expect if they are built properly, and considerably more if they are not. The ongoing work is responding to vendor changes and occasionally replaying a failed batch. What creates constant maintenance is missing error handling, no monitoring and no documentation — which is exactly what we are usually replacing.