API Development: Connecting Systems Cleanly Instead of Gluing Them

"We just quickly need an interface." That sentence has blown up more software projects than any other requirement. It sounds so small. It never is. APIs are the places where your system meets systems you do not control — and that is exactly where the most expensive surprises arise.

This article explains, from practice in the Munich area, when a dedicated API really makes sense, when it only creates complexity without benefit — and how to tell a clean integration apart from a glued-together one. Honestly, without buzzword bingo.

1. What an API actually is — without jargon

An API (application programming interface) is a contract between two systems: "If you ask me like this, I will answer you like that." No more, no less. The value of an API lies not in the technology but in this contract — it makes two systems independently changeable.

The opposite of this is "gluing": two systems that access each other directly, the other's database, internal files, undocumented behaviour. That works — until one of the two systems changes. Then the other breaks along with it, often on a Friday afternoon.

A good API is at its core an insurance policy against exactly that moment. You pay a little more while building, so that both sides can later evolve independently without destroying each other.

2. When a dedicated API does NOT make sense

Before we talk about the when, the honest when-not — because a dedicated API is not an end in itself.

When there is only a single consumer and that does not change. If exactly one system fetches data exactly once, a full-fledged API is often over-engineering. A simple, well-documented data export is enough — and costs a fraction.

When the target system already has a usable API. Very often the right answer is to cleanly use the existing API of the ERP, CRM or shop, instead of building your own intermediate layer that only adds complexity.

When the data volume is tiny and the frequency rare. A nightly sync of 200 records does not need a real-time API. Here a simple scheduled job is more robust and cheaper.

The rule of thumb: a dedicated API pays off as soon as multiple consumers, regular changes or different speeds are in play. Otherwise you are building infrastructure for a problem you do not have.

3. The three expensive truths about interfaces

From many integration projects, three truths have crystallised that are almost always underestimated in the first proposal.

First: foreign systems fail. Not whether, but when. A professional integration treats the failure of the other side as the normal case, not as the exception — with retry logic, queues and clear error states. Anyone who leaves this out builds a demo, not a product.

Second: data models never fit together cleanly. Your "customer" is not the ERP's "customer". The translation between two data worlds — the mapping — is the actual, often invisible effort. There is more work here than in the connection itself.

Third: APIs are never finished. The other side changes its API, deprecates fields, changes limits. An integration is not a building, it is a relationship that must be maintained. That belongs in the follow-up cost calculation.

4. How to recognise a clean integration

You do not have to be a developer to judge quality. Watch for:

• It survives an outage of the other side. If the ERP goes down for an hour, no data is lost — it is caught up afterwards.
• It is observable. You can see whether the interface is working, hanging or producing errors — without digging through log files.
• It is documented like a contract. What goes in, what comes out, what happens on errors — in writing, not in one person's head.
• It is idempotent. If it accidentally runs twice, no duplicate record is created. Sounds technical, but in the mid-market it is hard cash.

These properties are not a luxury. They are the difference between an interface you forget about and one that costs you a support case every month.

5. API development in the Munich mid-market context

In the Munich area we often see the same constellation: a grown ERP, a CRM, perhaps an online shop, and people in between copying data manually. The temptation is strong to buy a big integration platform straight away. Often a lean, well-built API layer is enough — exactly for the two or three paths that really hurt.

API development is rarely a standalone project. It is almost always part of something bigger — a new piece of custom software, a modernization, a platform rollout. That is why this article belongs in the larger context we set out in the guide to custom software development.

If your interface problem stems from an old system, it is worth a look at Legacy modernization — APIs are often the first, lowest-risk step to defuse an old system. And if you are wondering whether your project runs better as a fixed price or iteratively: Fixed price vs. agile answers exactly that, honestly.

More about our approach can be found on the page about custom software and app development.

Conclusion

An API is not a technical detail but a contract that keeps two systems independent. It is not always the right answer — but when it is, its quality decides the operating cost of the years to come.

Sources

This article is based mostly on our own project experience from integration and API projects in the Munich area. Where we refer to established architecture knowledge (direct database access as an antipattern, the interface as a low-risk first modernization step), the primary sources are linked below.

• Our own project experience from integration and API projects for mid-market companies in the Munich area
• Martin Fowler: Integration Database — why reaching directly into foreign databases glues systems together
• Martin Fowler: Strangler Fig Application — an API layer as a low-risk first step
• Guide: custom software development — the larger context
• Legacy modernization — APIs as a low-risk first step
• Fixed price vs. agile — the process model for integration projects