At some point a vendor, a developer, or an article has told you that a tool "has an API," and you nodded along. So let me answer the underlying question plainly: what is an API, and why should a business owner who will never write code care about it?

Short version: an API is the way one piece of software talks to another, without a human in between. It is the difference between your systems working as one machine versus your staff retyping the same data into three screens. And "does it have an API?" is, I would argue, one of the three most important questions to ask before buying any business software, right next to price and ownership of your data.

Here is the explanation I give clients, with the practical payoff at the end.

The waiter metaphor, done properly

You have heard software people compare an API to a restaurant waiter. The comparison is good, but it usually gets cut short, so let me run it fully.

You sit in a restaurant. The kitchen is where the real work happens, but you are not allowed in the kitchen. You do not need to know how the stove works, where the ingredients are stored, or who is cooking. Instead:

  1. You get a menu: a fixed list of things you are allowed to order, described in a standard way.
  2. You give your order to the waiter, in the format the menu defines. "Nasi goreng, no chili, extra egg."
  3. The waiter carries the request to the kitchen, the kitchen does its private work, and the waiter brings back exactly what you asked for, or a clear message about why not ("sorry, we are out of egg").

An API is the waiter plus the menu. One system (say, your online store) places a structured order with another system (say, your accounting software): "record this sale, Rp 350,000, customer Budi, paid via transfer." The accounting system does its internal work and replies: "done, here is the record number." Neither system needs to know how the other works inside. They only need to agree on the menu.

The part people skip: the menu is a contract. It is published, stable, and the same for everyone. That is what makes APIs powerful. Any system that can read the menu can order from the kitchen, which means your tools can be connected in combinations the original vendors never imagined.

What this looks like in a real business

Abstract definitions do not sell decisions, so here are concrete flows that APIs make possible, all common in Indonesian SMEs in 2022:

  • Online store to accounting. A sale on your web store automatically creates the invoice and journal entry in your accounting tool. Nobody retypes anything, and month-end closing stops being archaeology.
  • Payment gateway to order system. A customer pays via virtual account, the payment gateway's API notifies your system within seconds, and the order flips to "paid" without anyone checking a bank statement.
  • Logistics. Your system sends shipment details to the courier's API and receives a tracking number back, then polls for delivery status. Your customer service stops answering "sudah sampai mana?" all day.
  • Marketing. A new customer in your point-of-sale is automatically added to your email or WhatsApp list, tagged by what they bought.

Every one of these flows replaces the same thing: a human copying data from screen A to screen B. That work is slow, boring, and error-prone, and it silently caps how much your business can grow before you must hire another admin. This is also the plumbing that makes broader automation possible, the kind I describe in Automating Your Back Office With AI Workflows: none of it works if your tools cannot talk to each other in the first place.

Why "does it have an API?" belongs in every purchase decision

Here is the practical payoff, and the reason I wrote this article.

When you buy software, you are not just buying today's features. You are choosing where your business data will live, and how easily it can leave or connect. A tool without an API is a room with no doors: your data goes in through the keyboard and comes out, if at all, through manual exports.

I call these tools data prisons. They feel fine at first. The pain arrives in year two or three, when:

  • You want your POS sales to flow into new accounting software, and the answer is "export to Excel every day and import manually."
  • You want to leave the vendor, and getting your own customer history out requires begging their support team.
  • You want one dashboard across sales, stock, and cash, and it is impossible because one system in the chain cannot share anything.

The tragedy is that this is invisible at purchase time. Two tools look identical in the demo, one has an API and one does not, and the price difference is small or zero. The difference only shows up later, as either an afternoon of integration work or a permanent tax on your operations.

So before you buy anything, ask the vendor, in writing:

  1. Does it have an API? If the salesperson does not know, that itself is information.
  2. Is there documentation I can see? Public docs signal a real, maintained API. "We can build an integration for you, custom" usually means expensive and fragile.
  3. What does API access cost? Some vendors lock the API behind the top-tier plan. Fine, but know it before you commit.
  4. Can I export all my data myself, anytime? The escape-hatch question. Even with no API, full self-service export keeps the door unlocked.

You do not need to understand the technical answers. You need the answers on record, and a technical advisor can evaluate them in ten minutes. This is the same reasoning I apply to platform decisions generally in Tech Stack Choices for Non-Technical Founders: the expensive mistakes are the ones that are cheap on day one.

A short word on limits

To keep this honest: an API is a capability, not a finished feature. "It has an API" means the door exists, not that the rooms are connected. Someone still has to build or configure the connection, a developer, or increasingly in 2022, a no-code tool like Zapier or Make for simpler cases. Budget for that work. Also, APIs vary in quality: some are complete and well-documented, some expose only a fraction of the tool's data. Hence the "show me the documentation" question.

None of that weakens the core point. A mediocre API can be worked with. No API cannot.

The takeaway

So, what is an API? It is the waiter and the menu between your systems: a published, structured way for software to request work from other software with no human retyping in the middle. Businesses whose tools talk to each other run on connected pipelines. Businesses whose tools do not, run on staff-powered copy-paste, and they pay for it every single day without seeing the invoice.

The action item is one sentence long: from today, no software purchase without asking "does it have an API, and can I see the documentation?" It is a free question, and years from now it will be the reason your systems fit together instead of holding your data hostage.