What an API is, and why it matters whenever you buy software

An API is, in short, the door through which one program can ask something of another program. Not through the interface you see, but directly, automatically, with no person in the middle.

The restaurant analogy

You are at a table. You do not walk into the kitchen to get your food, and the chef does not come out to ask what you want. There is a waiter and a menu: you order from the menu, the waiter carries the order, the kitchen prepares it, the waiter brings it back.

The API is the waiter plus the menu. The menu says what you can ask for — “give me last month's orders”, “add a new customer”. The waiter carries the request and brings the answer. The kitchen stays closed, and that is better: you do not need to know how it works, and you cannot break anything.

What it looks like in practice

Three common situations, all solved through an API:

• The online shop sends the order automatically to the invoicing software. Nobody retypes anything.
• The field application marks a job finished, and the management system knows immediately.
• The website shows real stock, because it asks the warehouse every time, not once a day.

Without an API, all three are done by a person copying from one screen to another. It works — until volume grows.

The questions to ask before buying any software

1. Is there an API, and can I see the documentation right now? If the answer is “yes, of course” but the documentation never appears, it probably does not exist.
2. What can be done through it, and what cannot? Many systems only allow reading. If you want to write too, ask explicitly.
3. Does it cost extra? Some suppliers put access in a higher tier. Better to know before, not after.
4. Are there limits? How many requests per minute, per day. It matters if you want real-time synchronisation.
5. What happens when it changes? A serious supplier announces changes in advance and keeps the old version running for a while.

The sign that a supplier does not want you to leave

A system with no API, or one that only allows reading, is a polite form of captivity. The data is yours, but you cannot move it without retyping it.

That is why the API question is not technical, it is commercial: it is about how easily you can change supplier in three years.

What goes wrong with integrations

The two systems do not mean the same thing by “customer”

In one, the customer is the company. In the other, the contact person. That is not a technical problem, it is a definition problem, and it gets solved before any code is written — otherwise it gets solved three times.

Nobody thought about what happens when the link drops

A good integration retries what failed on its own and tells somebody if it still does not work. One written in a hurry loses data silently, and that gets discovered months later.

Everything syncs, all the time

You do not need all the data in both systems. Decide what crosses over and in which direction. Less means less to repair.

The practical conclusion

You do not need to understand how an API works. You only need to ask whether one exists, what it allows, and whether you can see the documentation. Three questions that can save you a painful migration a few years from now.

← Back to the blog