In short
An API is the defined point where two programs talk to each other. It sets out which questions one system may ask and what shape the answer comes back in. Without one, two systems exchange data through people retyping it. With one, they do it directly, in seconds, and without typos.
The analogy that holds
An API is a restaurant menu. It states what can be ordered and how to phrase the order. What happens in the kitchen is none of the diner's business — and that is exactly the value: the calling system does not need to know how the other one is built.
That is why a good API survives a rebuild of the system behind it. Reach into another vendor's database directly and you are bound to its internals, which break at the next update.
Where it goes wrong in practice
The most common case in Swiss SMEs: the ERP has an API and nobody ever switched it on. The second most common: it is on, undocumented, and the vendor charges per call.
The third is the expensive one — there is no API. Then you are left with file exports on a schedule. It works, it is never current, and every error surfaces a day late.
What an integration actually costs
Not the connection. The connection is a day's work. The cost is in the edge cases: what happens when the target system does not answer? When a record arrives twice? When someone edits it mid-transfer?
An integration without those answers runs well for six months and then quietly produces wrong data. Which is why every integration needs logging that shows what was transferred — and a way to replay a run.
How we handle it
Integrations are among our most frequent jobs. The brief is almost never «build us an API». It is «these two systems know nothing about each other, and that costs us a day every week».
How we work: integrations. When the transfer carries decisions rather than just data, it belongs to process automation.
Related terms
A term in your quote that nobody explained?
In a strategy call we translate the offer in front of you — even when it did not come from us.