API integration for SMEs: the four questions before any code

Building the connection is the easy part.

Wiring two modern applications together often takes less than a day. Integration projects in SMEs do not fail on the connection. They fail on four questions nobody answered first: which fields move, which system is right, how often, and what becomes visible when the link breaks.

This piece works through those four, and the three technical decisions that hang off them.

What an interface carries is not a technical question

An API is a defined point where two programs talk to each other. It sets out what can be requested, how the request must look, and what shape the answer comes back in.

What it does not set out: which data you want to move. No documentation answers that part.

The common assumption is that a good integration synchronises as much as possible. The opposite holds. A good integration moves exactly the fields the other side needs – and not one more. Every extra field is a field that will eventually exist in two versions.

The question that comes before any connection: which system leads?

If a customer address sits in both the CRM and the ERP and both can be edited, one of them wins at the next sync. Which one has to be decided before the interface runs.

Without that decision, the system alternately overwrites whichever correction was more recent. It goes unnoticed for weeks and is close to impossible to reconstruct afterwards.

The rule is simple and still usually skipped: one leading system per field. Not per application – per field. The address can lead in the CRM, stock levels in the ERP, payment status in accounting.

Polling or being told

There are two ways a system learns that something changed.

With polling, system A asks system B at fixed intervals whether anything is new. Simple to build, and in 95 per cent of those calls the answer is nothing.

With a webhook the direction reverses: system B announces the change itself the moment it happens. A new contact in the CRM fires a message, and the receiving system acts on it.

The difference is not only efficiency. A webhook delivers the change as it occurs. Hourly polling delivers it half an hour later on average.

The cost: a webhook that lands nowhere because the target was briefly down is simply lost – unless someone built a retry. That gets forgotten at build time and surfaces at the first outage.

Real time is usually the wrong question

«Real time» reads well in every proposal and is unnecessary in most processes.

Stock levels are minute-sensitive: sell an item that is already gone and you have a customer problem. An address change can wait until tomorrow morning. That difference is commercial, not technical – which is why no supplier can decide it for you.

The more useful question is: what does it cost if this information is an hour old? If the answer is nothing, you have just removed an expensive requirement.

Custom interface, iPaaS or middleware

Three routes, and the field genuinely disagrees about which suits small companies.

The custom interface

Written directly against the process. Full control, no recurring licence. In exchange somebody owns the maintenance – and when a vendor changes their API, that is your problem.

iPaaS

A platform shipping ready-made connectors between known applications. Fast to set up, often without code. Demand for the term is measurable but thin: 90 searches a month in Switzerland at a difficulty of 12 – a word vendors use more often than customers do (Semrush, Swiss database, September 2026).

The argument is about billing. iPaaS vendors mostly charge per task. At 200 orders a month that is cheap. At 20,000 the same connector can cost more than the development it replaced. The counter-argument points at the maintenance you no longer carry, and that is fair.

Middleware

A layer in between that connects several systems instead of wiring each pair separately. It earns its place once three or more applications are involved: four systems already allow six direct connections, five allow ten.

Our position, and it is a position rather than a measurement: below three systems a custom interface is almost always cheaper. From three upward the layer is worth asking about. Whether iPaaS or self-built is decided by the volume arithmetic above, not by principle.

What happens when the interface fails

It will fail. A vendor patches their servers, a certificate expires, a field gets renamed in an update.

The question is not whether, but what becomes visible when it does. Three things belong in from the start:

• A retry with backoff. Not immediate and not endless – otherwise the retry amplifies the outage.
• An alert to a human. An interface that fails quietly is noticed weeks later, when numbers stop matching.
• A log showing what did not arrive. Without it the only remedy is resending everything.

Putting an integration live without those three has not produced an integration, but a dependency.

Security: three places it goes wrong

The credential itself. An API key is a password with full access – it does not belong in source code or in a file that travels with the project. More on that under IT security.

The scope. Many vendors hand out keys with full rights even when the connection only needs to read. Read-only access that cannot change anything does markedly less damage if it leaks.

The payload. Every field you move then exists in two places. With personal data that is a question under data protection law, not only a technical one.

Migration is not integration

Two things constantly confused, because both mean «data from A to B».

A migration happens once: the records move, and the source is then dead. An integration runs continuously: both systems stay, both keep working.

The difference decides the preparation. Before a migration you clean the records once. Before an integration you settle which system leads on which field – otherwise the duplicates simply travel faster. How to recognise a data silo in the first place is covered in our piece on data silos between ERP and CRM.

When it pays off for an SME

The arithmetic is unromantic. Take one task somebody currently retypes by hand. Count how often it happens per month and estimate the minutes.

Twenty orders a month at five minutes is under two hours. Nobody builds an interface for that. Two hundred orders at five minutes is more than two working days – there automation pays for itself inside a quarter.

The second and underrated item is errors. Manual transfer produces typos, and a wrong stock level or a wrong invoice address costs more than the five minutes it saved.

An interface does not yet automate a process

A connection moves data. It does not decide what should happen next.

That is where many projects stall halfway: the systems talk, but nobody defined the sequence that follows. The second step belongs to process automation – the interface is the precondition, not the outcome.

How we connect systems and what comes out of it sits under integrations. If the work needs an application of its own, that is a question for web apps; once the connection runs in production it belongs in a managed service with an agreed SLA.