What is an API? An explanation without technical jargon

You hear the word everywhere. Your supplier has one, your software has one and someone suggests connecting "via the API". But what is an API exactly, and when is it useful for your organisation? Below is an explanation without technical jargon, with examples from practice.

What is an API?

An API is a fixed way in which software talks to other software. The abbreviation stands for application programming interface. It is a set of agreements: send a request in this format, and you get a response back in that format.

A comparison helps. In a restaurant you do not walk into the kitchen yourself. You give your order to the waiter, who takes it to the kitchen and comes back with your food. You do not need to know how the kitchen works, only how to order. The waiter is the API.

How does an API work in practice?

Take a website where customers book something and pay straight away with iDEAL. You do not build iDEAL yourself, but use the API of a payment provider such as Mollie or Stripe.

1. The customer clicks pay.
2. Your website sends a request to the payment provider's API: create a payment for this booking.
3. The API responds with a link to the payment page.
4. The customer pays at their own bank.
5. The payment provider lets your website know the payment succeeded, after which the booking is confirmed.

Two systems work together without either needing to know anything about how the other is built internally.

What can you do with an API?

Almost all modern software has an API. That opens up four kinds of possibilities.

Retrieving data

Showing information from another system on your website or in a portal: current stock, product specifications, appointments from a planning system or reviews.

Sending data

Someone fills in a form and the details go straight to your CRM. No retyping, no exports.

Triggering actions

Something happens and another system needs to respond. A new order starts shipping at your fulfilment partner, a cancellation removes someone from your mailing list.

Keeping systems in sync

The same customer data in your CRM and your accounting stays in sync automatically. How to set that up is explained in syncing data between systems.

What does an API deliver?

The main benefit is that manual work disappears. Data that moves automatically from system to system does not need to be retyped by anyone, and what is not retyped cannot go wrong either. Data is also available immediately instead of after the next export. And what works for ten records also works for ten thousand.

A second benefit is flexibility. You are not limited to what a package can do as standard. If there is an API, you can extend or combine software into exactly what you need.

What are the limitations of an API?

An API is a door, not an integration. Something has to call the API: an automation tool such as Make, your own middle layer or the code of your application.

Also:

• Not everything has an API. Some software is closed. Check this before you choose a package.
• Not every API can do everything. Sometimes you can only read and not write, or exactly the fields you need are missing.
• APIs change. Suppliers release new versions. An integration needs maintenance.
• There are limits. Most APIs limit the number of requests per minute. With large amounts of data, an integration has to handle that smartly.

When does an API become relevant for you?

For simple integrations between well-known tools, a standard integration is often enough. It becomes interesting when:

• there is no standard integration, but the software does have an API
• the standard integration almost does what you want, but not quite
• you have large volumes for which standard tools become too expensive or too slow
• you are building something of your own, such as a portal, dashboard or internal tool, that needs data from other systems

In those cases a custom integration is often the logical step.

How we work with APIs

Virtually everything we build runs on APIs. Websites retrieve data from a back end, applications talk to payment providers, email services and business software. Which technology we use for that, we choose per project, depending on what it needs to do and who manages it.

You do not need to understand the technology. It is enough to know that if two systems should work together, there is usually a way. Do you have systems that currently work past each other? Take a look at our system integrations and application development, or ask your question.