Knowledge Base · AI and software

API and integration

An API is an agreed way for one program to request data or an action from another. An integration is the concrete connection of 2 systems over such an agreement - an online store and accounting software, for instance - so data moves automatically instead of being retyped by hand.

What it looks like in practice

Picture a service counter with a clearly posted list of what may be requested and in what form. One program sends a request following that rule, and the other replies with data.

For an online store that means a new order arriving automatically in accounting, stock levels decreasing and the customer receiving a confirmation - without a single manual step.

To the user it is all invisible. Only the consequence shows: the data is identical everywhere and nothing is retyped.

What integration actually solves

Retyping. It is the most expensive quiet cost in small companies - someone manually moving the same data from an email into a spreadsheet, then from the spreadsheet into a program.

Errors. Every retyping carries the risk of a wrong amount or date, and such an error can cost more than the whole integration.

Delay. Data transferred once a day means decisions are made on yesterday’s position.

Integration is also a precondition for AI automation, because the system needs somewhere to read data from and somewhere to write it to.

What to check before commissioning

Whether the other side even has an API. Older programs, particularly local accounting packages, sometimes have no access route at all - and then integration is not a question of price but of feasibility.

What the documentation and limits look like. The number of permitted requests and the authentication method determine how complex the job is.

Who owns the access credentials. Keys must be registered to your company, like everything else.

What happens when the other side changes its rules. Integrations break when a provider alters their system, so maintenance is worth agreeing as well.

When it does not pay off

When the volume is small. If data moves ten times a month, manual entry is cheaper than building and maintaining a connection.

When processes are unstable. There is no sense automating a flow that changes every couple of months - settle the process first, then connect it.

When a simpler solution exists. Sometimes exporting and importing a file once a week solves ninety percent of the problem at a fraction of the cost.

That is why, before quoting, we always measure how many hours a month that transfer actually consumes.

What a typical connection project looks like

The first step is a list of the data that currently moves between systems by hand, with an estimate of how many hours a month it consumes. Without that number there is no basis for a decision.

The second is checking both sides. Does each system have an access route, what are the limits, and what may be read versus written. This is where projects most often stop, with older local programs offering no access at all.

The third is building and testing on real data, with mandatory error handling. A connection that works while everything is tidy and fails silently on unexpected input is worse than manual entry, because the mistake is noticed late.

The fourth is monitoring. An integration should report when something does not go through, rather than that being discovered during month-end reconciliation.

The fifth is an agreement on maintenance, because rules on the other side change without notice.

Last updated: 17 August 2026

Need this applied to your own site?

Send the address and we will tell you where you stand - no obligation.

Send an enquiry