Skip to content

What is an API? Interfaces explained clearly

An interface is an agreement between two systems: who asks what, who answers what, and what applies when something goes wrong. The last part is the most important — and the one most often missing in projects.

  • ForCompanies, project managers
  • LevelBasic to intermediate
  • Reading timeabout 7 minutes
  • Updated16 October 2026

What you will learn

  • What an interface is, technically and organisationally
  • How a request and its response are structured
  • What the difference is between polling and notification
  • Which six questions must be settled before any interface

An interface is an agreement

When a shop passes an order to the inventory management system, the two systems do not simply talk to each other. There is a defined place where one system can make a request, a defined form for that request, a defined form for the response — and an agreement on what applies when something is missing.

This agreement is the interface, in English an Application Programming Interface, or API for short. The technical part is often the easier one. The difficult part is agreeing which fields are mandatory, which values are permitted and who decides in the event of contradictions.

How a request works

System A · Shop

  • Order is placed
  • Request to the interface
  • Waits for response

Interface

  • Checks login and permissions
  • Checks the data for completeness
  • Translates fields and formats
  • Responds: accepted, or rejected with a reason

System B · Inventory management

  • Creates the order
  • Returns an order number
  • Rejects if an item is unknown
An interface does not only transfer data — it also answers what happens on a rejection. This return path is the part that is most often missing.

Three things stand out in this diagram. First: the interface checks before it passes anything on — otherwise faulty data ends up in the target system. Second: it translates, because two systems almost never name the same thing the same way. Third: it also responds when it rejects something, and does so with a reason.

Polling or being notified

There are two basic patterns, and the choice between them has practical consequences.

  • Polling: Your system asks regularly — "are there any new orders?". Easy to build and robust against outages, but with delay and unnecessary requests.
  • Notification: The other system gets in touch as soon as something happens — often called a webhook. Fast and economical, but it needs a reachable address on your side and a plan for lost messages.

In practice the two are often combined: notifications for the normal case, a regular poll as a safety net underneath. This duplication is not extra effort without reason — it is the answer to the question of what happens when a message is lost.

An example from practice

The order nobody saw

A shop reports every order to the inventory management system by notification. On a Tuesday the inventory management system is unreachable for twenty minutes. The shop sends the messages, gets no response — and discards them. Four orders are missing, and it will only be noticed at the monthly reconciliation.

The solution is not more technology but an agreement: messages are repeated until they have been confirmed, and anything that still has not arrived after several attempts ends up in a list that a person sees. This includes the rule that a message delivered twice does not create a second order.

The failure case is half the work

An interface that works in the normal case is half finished. This includes:

  • Recognisable error responses: not "error", but which field and why.
  • Repeatability: the same message delivered twice must not create two transactions.
  • Traceability: what was transferred when, and what came back?
  • A place for hopeless cases: transactions that still fail after several attempts must come to someone's attention.

These four points distinguish an interface you can operate from one that works only as long as nobody is looking.

Six questions before any interface

  • Which system leads? When data contradicts, one side must win.
  • Which fields are mandatory, and which values are permitted?
  • How is authentication done, and who manages the access keys?
  • How often and in what volume is data transferred? Are there rate limits?
  • What happens on a rejection — retry, discard, notify someone?
  • Who notices when the connection has not run for three days?

Anyone who answers these six questions before building has the difficult part behind them. Anyone who skips them will answer them later in operation — under time pressure.

Common misconceptions

An existing interface saves you building it, not the coordination: field mapping, permissions, volumes, failure cases and tests remain.

It transfers data and answers questions about whether it was accepted. Only the second part makes it operable.

Often it genuinely is — and then it is the right choice. What matters is how up to date the data needs to be and how errors come to attention.

Further sources

Read on

API integrationOur service on the topic.
Connecting Excel, email and specialist softwareThe most common reason for an interface.
PHP in the backendWhat happens to incoming data on the server side.

About the author

Fabian Lücker is managing partner of PHP-Schmiede KG in Rheine and has worked in software development since 2007. He is responsible for development and design, and writes here about decisions that come up in real projects.

Questions about the article? Write to us

Two systems that do not know each other?

Tell us the two sides and what is to be transferred. We will work through the six questions with you.

Discuss an interface