APIs: the digital glue

Most companies don’t run one system but a dozen: ERP, shop, CRM, PIM, time tracking, shipping, accounting. Grown over years, bought at different times, from different vendors. As long as data moves between these systems by hand, every change costs time and produces errors. An API is the point where two systems talk to each other directly instead.

What an API does technically

API stands for Application Programming Interface. It means the part of a piece of software through which other software talks to it: defined calls, defined data formats, defined behaviour. Anyone who knows the interface does not need to know the code behind it.

That separation is exactly where the benefit lies. A shop that queries stock levels via the ERP’s API does not need to know how the ERP calculates internally. If the database behind it changes, the interface stays the same and the shop keeps running.

In practice, REST dominates: resources over HTTP, JSON as the format, described with OpenAPI. You will come across SOAP mainly in older ERP and banking systems. GraphQL pays off when many different clients need different slices of the same data. gRPC where internal services talk to each other a lot and fast.

What an API saves in operations

Take the simplest case: data sits in one database and is needed in another piece of software. Without an interface, that means export, convert, import: three steps, each by hand, each a source of errors. Once, that is bearable. Every day, it is a part-time job.

An API takes over exactly these three steps. It fetches the data, brings it into the form the target system understands and delivers it, on a schedule or triggered by an event. There is a second effect: a platform with an open interface can be extended without waiting for the vendor. Your own modules hook into the API instead of sitting in the core of the software.

Where APIs work in everyday life

You often use APIs without noticing. In an online shop, the connection to the payment service provider is the most visible one: it is what makes card payments and other instant payment methods possible in the first place.

What runs in the background at the operator’s end stays invisible: the merchandise management system that supplies stock levels and prices, the shipping partner that returns labels and shipment status, the ERP that automates invoices and bookings.

Customer portals are the second big case. There, the CRM is usually connected via an interface: existing customer data is read, added to in the portal and written back. That way one system remains the leading source, instead of the same addresses being maintained in three places and drifting apart.

Why the topic is gaining weight

Software increasingly comes as a service rather than an installation. That shifts the integration work: it is no longer the database in your own basement that gets tapped, but the vendor’s interface. Anyone buying an application today therefore checks first what its API can and cannot do.

Then there is automation. A process that runs across two systems and has a manual handover at the boundary is not an automated process. Only the interface closes the gap and makes the workflow measurable, repeatable and monitorable.

How we approach interfaces

It starts with taking stock: which systems are involved, which data flows where, which one is the leading source, how often it needs to be synchronised. Only then is it decided whether an existing interface is enough, whether a custom one is needed or whether a service bus belongs in between, bundling the translation for several systems in one place.

We build such connections for ERP systems, shops, portals and cloud services, from a single interface to an integration layer that connects several surrounding systems. Details are under Software development.

If you have a specific integration ahead of you: describe the two systems to us and what should flow between them. From that we can estimate how much effort is involved. Get in touch with us.