Skip to content

Guide · 7 min read

What is an API? A plain-English guide

You have heard "we can connect that via API" in a dozen meetings. Here is what that sentence actually means, with no code and no jargon.

Definition

The short version

An API (Application Programming Interface) is just an agreed way for two pieces of software to ask each other for something and get a useful answer back — without a person copying and pasting between them.

It is not a product you buy or a specific piece of technology; it is more like a set of rules two systems agree to follow so they can talk to each other reliably.

Analogy

A plain-English analogy

Think of a restaurant.

You do not walk into the kitchen and cook your own meal. You tell the waiter what you want, the waiter takes a very specific, structured order back to the kitchen, and brings back exactly what you asked for. You never need to know how the kitchen works internally.

An API is the waiter.

Your ERP does not need to know how your accounting software stores its data internally — it just needs to know the specific, agreed way to ask for it ("give me the current stock level for part 4471") and how to understand the answer it gets back.

Examples

What this looks like in a real business

A few concrete, everyday examples of APIs at work, described in business terms rather than technical ones.

Sales to ERP

A sales order placed on your website automatically appearing in your ERP, because the website's system asks the ERP's API to create it — instead of someone re-typing it.

Bank to accounting

Your accounting software automatically showing today's bank transactions, because it asks your bank's API for them each morning.

Store to courier

A shipping tracking number appearing on a customer's order confirmation email, because your store's system asked the courier's API for it the moment the label was printed.

In each case, two systems built by two different companies are exchanging exactly the information needed, in a format both sides agreed on in advance.

Integration decisions

Why 'does it have an API' is the right question to ask

When a business is deciding whether two systems can be connected, whether one has a usable API is usually the deciding factor.

A modern system with a well-documented API can usually be integrated in days to a few weeks. A system with no API, or a poorly documented one, usually means either manual data entry stays in place, or a slower and more fragile workaround (like reading exported spreadsheets) has to be built instead.

This is why "does [system] have an API?" is one of the first questions worth asking before buying new software, not something to figure out after the contract is signed.

Reality check

Common misconceptions

Three things people often get wrong about APIs.

"API" does not mean "automatic"

An integration still has to be designed, built, tested and maintained. The API is what makes that possible, not something that does it by itself.

Great APIs do not guarantee compatibility

Two systems can both have great APIs and still need real design work to map one's data correctly onto the other's.

Not all APIs are equal

Some are comprehensive and well-documented; others expose only a fraction of what the system can actually do, which limits what is realistically possible.

Practical checklist

Questions worth asking your vendor or IT partner

Does this system have a documented, public API (not just an internal one)?

Is there a limit on how many requests can be made per minute or day, and would our volume hit that limit?

Who is responsible for maintaining the connection if the vendor changes their API in future?

Does the API give access to the specific data or actions we actually need, or only a subset?

Next steps

Work out whether your systems can be connected.

If you are weighing up whether two of your systems can realistically be connected, that is exactly what a discovery call is for.

Related reading

Prefer to talk it through? A 30-minute call is usually enough.

Bring us the process that is slowing you down.

A 30-minute discovery call is enough to work out whether automation is the right answer, and what it would take.