What is an API — a plain-language explainer, and why it belongs in your contract

An order lands on your website. One person retypes it into the accounting system, another logs it into the courier panel, a third switches to a separate tool just to send the customer a text. Three systems, three manual steps — three separate places where something can go wrong.

Somewhere in a vendor call, someone says "we can connect that through the API," and most owners nod along without knowing exactly what was just promised. The result is either paying for work that wasn't needed, or never getting the thing that actually was needed: systems that pass data to each other on their own.

What an API actually is — no jargon required

API — Application Programming Interface — sounds technical, but the mechanism is closer to a waiter in a restaurant. The kitchen (one system) and the table (another system) never speak directly; the waiter takes the order in a fixed format, carries it to the kitchen, and brings the result back the same way. An API does the same job: one program asks another for something and gets an answer back in a predictable shape, with nothing left to guess.

Knowing this matters for a money decision, not out of curiosity. When someone says "we'll integrate that," it can mean the systems will exchange data on their own — or it can mean someone will export a file once a week and paste the numbers in by hand. Both get called "integration," but one is a one-time setup and the other is a recurring line item on someone's salary. Three questions tell them apart: what data moves, in which direction, and is it automatic or manual? Ask them on the next vendor call — if the answer is "manual," the word "integration" shouldn't be in that sentence.

The same data, typed into three places — where the loss actually hides

The most common pattern: the site records an order, someone retypes it into the accounting system, logs it again in the courier panel, and a third person is supposed to remember to send the text message. Every retype costs a few minutes and carries its own chance of a mistake. At low order volume, nobody notices. At ten or twenty orders a day, the hours add up on their own, and the error rate isn't one number — it's a separate risk sitting at every single handoff point.

The real cost runs past time itself: if a phone number gets mistyped and the text never goes out, the customer has no idea what happened to their order, and next time they buy somewhere else. Seeing this doesn't take a report — it takes one question to your team this week: how many different systems does a single order get typed into by hand? If the number is above two, the problem already exists, it just hasn't been counted yet.

Not every system has an API — how to check before you buy

Shopping for a new system — a payment provider, a courier service, accounting software — almost always gets you the answer "sure, it integrates." That sentence proves nothing on its own. Some systems genuinely have a documented API: an open, described connection point other software can use. Others don't, and "integration" quietly means "our staff will coordinate with your staff."

Checking the difference before you buy takes about a minute: ask for a link to the API documentation. If it exists, it gets sent within minutes. If there's no link and the answer is "let's discuss that separately," that is the answer — that system will tie you to manual work for years, and "integration" stays a word on a slide. Run this check on the next system you're about to choose, before the signature, not after.

Webhooks — why a system that "writes itself" is the reliable kind

There's one question that separates a real integration from a weekly spreadsheet export: what happens when a request fails. In a manual setup, someone forgets, goes on leave, gets sick — the data simply doesn't move, and nobody knows until a customer complains. A real API-and-webhook connection behaves differently: if the receiving system is briefly unreachable, the request isn't lost — it gets sent again a little later, and the result still lands.

That sounds like a small detail, but it's exactly where the value sits: automation only earns the name if it keeps working the moment a server doesn't answer for a minute, not just on the days everything goes smoothly. Next time someone tells you "we've set up an integration," one question is enough: what happens if the request fails? If the answer isn't "it retries," what you have is probably manual work wearing an automation label.

The API clause belongs in the contract — this is an ownership question

Say the integration is real and it works. What comes after is a legal question, not a technical one: who owns the access keys, the accounts, and the documentation of how the connection actually works? Most contracts skip this line entirely, because someone said "of course that'll be yours" out loud in a meeting. But when the vendor changes, the contract ends, or the relationship simply cools, a verbal "of course" turns into nothing — the next team either starts from zero or stays dependent on the old vendor to keep it running.

This isn't a technical detail, it's an ownership one: whose name the API keys and accounts are registered under, and who holds the documentation of how the pieces fit together. The concrete step for this week: open your current vendor contract and check whether that line exists. If it doesn't, add it at the next renewal — before the signature, not after.

Whether an API exists isn't a technical question — it's the one that decides whether the system ends up belonging to you or to the vendor.

If your website, payment provider, courier service and accounting system are still "talking" to each other by hand, fixing that isn't a big project — it's one specific connection. Our work connecting your systems through APIs exists for exactly this: we check which systems genuinely offer an API, the keys and accounts stay in your name, and the scope gets written down before anyone signs.