An API in plain language

An API is the front desk of a service. Behind that desk sits a whole system — a web shop, an accounting package, a weather service — with data and functions you never see and never need to understand. On the desk hangs a list: these are the questions you may ask, these are the things you may have done, and this is how you must ask. Stick to that list and you get an answer.

That agreement is exactly what the word means. API stands for Application Programming Interface: the fixed way one program can ask something of another. Not through a screen with buttons, but directly — software to software.

The most important thing about that desk is that you never have to go into the kitchen. You do not need to know which language the web shop is written in, what its database looks like, or which server it runs on. You ask your question in the agreed way and get the data back. That is also why APIs last so long: the service can be completely rebuilt on the inside without your integration noticing, as long as the desk stays the same.

Why does almost every service have one?

A website is made for people: you log in, click around and read from the screen. That works fine for one thing at a time, but not for a thousand. As soon as data has to go somewhere else, or something has to be repeated daily, a human is the slowest link.

That is why services offer an API alongside their website. The same data, the same actions, but in a form software can work with.

• Connecting: getting your orders into your accounting automatically, without retyping.
• Automating: an overview in your inbox or in a chat channel every morning.
• Combining: putting data from two services side by side that know nothing of each other.
• Building: your own app or dashboard running on the data of an existing service.
• Moving: getting everything out in one go when you switch to another service.

You have been using them all along

Even without knowing it, you sit behind APIs all day. When you see the delivery date on a web shop, that shop is asking the carrier. When you pay by card, the shop talks to a payment service. When you see a map on a contact page, that comes from a mapping service. Even the website you are reading now fetches data from another piece of software along the way.

And if you have ever worked with Make, Zapier or n8n: every 'ready-made connector' you click there is nothing more than an API that somebody wrapped up for you. This course takes off the wrapping paper — so you can keep going when that ready-made connector is not there.

What does such a question look like?

Surprisingly ordinary: like a web address. Below is a real question to a public weather service. With a little goodwill you can simply read what is being asked: give me the current temperature at this latitude and longitude — which is roughly Amsterdam.

And this is what you get back. No formatted page with images and buttons, but bare data in a fixed shape called JSON. Ugly for a human, ideal for software: every piece has a name, so a program can pick out exactly the right number without fail.

That is the whole idea. The rest of this course is nothing but this, only broader: how to read and adjust such an address, how to pick apart the response, how to not only fetch data but also write it, and how to make sure it keeps working when the service at the other end hiccups.