What is an API: the plain explanation for business owners

An API is a defined doorway one system offers another: a menu of requests the second system may make, and the shapes of the answers it will give.

Someone technical says it in almost every meeting now: we will connect the booking system to the invoices through the API. The owner nods. The sentence sounded like a detail, and asking what it meant felt like admitting ignorance about the machine the business now runs on. This page is the explanation that meeting should have included.

An API is a defined doorway one system offers to another. It is a menu of the requests the second system may make, and the shapes of the answers that will come back. That is the whole idea: a boundary with a published list of what may cross it. When a developer says the two systems talk through an API, they mean each side has published a doorway the other can knock on.

The waiter analogy holds because it captures the essential point: the menu defines what you may ask for, not how the kitchen works. You order from the list. The kitchen keeps its recipes, its rush, and its improvisation behind the door, and the food arrives in a form you can eat. Systems work the same: the API promises the requests it accepts, and everything behind it stays the provider's own business.

It matters to owners because integration, the connect our booking to our invoices wish, is decided at the doorways. If both systems offer a clean doorway and the fields line up, the connection is an afternoon. If one side has no doorway at all, or the two sides name the same thing differently, someone must translate between them and keep the translation working as each side changes. Just connect them ranges from an afternoon to a project, and the difference is knowable before you sign.

The failure versions repeat. The integration assumed inside a quote that turns out, weeks in, to be the whole project. The doorway that changed on the provider's side and quietly broke the connection, noticed only when the invoices stopped arriving. The data that synced in one direction when the team expected two, so the stock levels in one system drifted permanently out of truth.

So when someone says API, ask four questions: what data crosses, in which direction, how often, and what happens when the other side is down. Ask whether both systems actually offer the doorway before assuming the bridge is cheap, because one side publishing a menu is not the same as both sides being ready to serve. And log the connection, so its failures surface in a place someone checks, instead of being discovered by a customer.

None of this requires learning to code. It requires treating integration as a thing with a scope, a direction, and a failure mode, which is how we scope it in our own builds. Guidance, not guarantees: the specifics of any provider's doorway live in that provider's documentation, and they change without notice. The structure holds anywhere: name the data, name the direction, ask who is offering the door, and the sentence in the next meeting will mean something.