API basics for non-technical business owners

The short answer: an API is just the way one piece of software lets another piece of software talk to it — a set of doors a system opens so other systems can send and receive information automatically. You don't need to understand the technical detail. You need to know that APIs are what make integration possible, and to ask whether the tools you use have good ones.

What is an API, in plain terms?

Think of a restaurant. You don't walk into the kitchen and cook — you order through the waiter, using the menu. The API is the menu and the waiter: a defined way to ask a system for something ("give me this customer's details") or to tell it something ("record this payment") without needing to get into its kitchen.

That's genuinely all it is. A controlled, reliable way for one system to interact with another. The menu says what you're allowed to ask for; the waiter carries the request in and brings the answer back. Your tools do the same thing for each other, thousands of times a day, without anyone typing anything. When people say two systems "integrate," they mean each has a menu and a waiter the other can use.

Why does an API matter to me?

Because it's the difference between tools that can be connected and tools that can't. When two of your tools both have good APIs, they can share data automatically — one sends a new customer or a payment to the other, and no one re-keys it. When a tool has a poor API or none at all, connecting it is hard or impossible, and you're stuck bridging the gap by hand.

So the quality of a tool's API directly affects whether you can ever escape the manual bridging that causes the re-keying problem. It's not an abstract technical spec — it's the thing that decides whether your software can save you time or just adds another box to type into.

What should I ask, without getting technical?

You don't need to read documentation or understand the plumbing. A few plain questions get you what you need:

• •"Does it have an API?" — can this tool connect to other systems at all?
• •"What can it share?" — the important data, or only a limited slice of it?
• •"Does it integrate with [my other tools]?" — often there are ready-made connections to common products like Xero or popular CRMs.

You don't need the technical answers. You need to know the doors exist, and roughly what fits through them. If a salesperson can't give you a straight answer to "does it have an API and does it connect to my accounting software," that's useful information in itself.

A worked example: an API doing its job

Here's an API at work, in plain terms. A customer pays an invoice in Xero. Xero's API lets your operational system ask, in effect, "has invoice 1043 been paid?" — and get a straight answer back, instantly, without anyone checking manually. The moment it's paid, your system can mark the job as settled, release it for delivery, and update the customer's record. No one logged into Xero, read the screen, and copied the status across. The two systems had a quiet conversation through the API and sorted it out themselves.

That's the everyday reality of a good API: dozens of these little exchanges happening in the background, keeping your systems in step. Xero and MYOB both offer strong APIs precisely because so many Australian businesses need exactly this kind of link between their operation and their books. When people say a tool "integrates with Xero," this is what they mean — its menu and waiter know how to talk to Xero's.

What makes an API "good" versus one that holds you back?

Not all APIs are equal, and the difference matters without you needing to read a line of code. A good API shares the data you actually need — customers, orders, invoices, payments, GST codes — and lets systems both read and update it reliably. A poor one might only expose a thin slice, or only let you read and not write, or be so limited that connecting it barely saves any manual work.

The practical test is what the connection removes. If a tool's API can carry the information that's currently being re-keyed, it's good enough to matter. If it can't reach the data that causes your double-handling, then on paper it "has an API" but in practice it still leaves you bridging the gap by hand. That's why "does it have an API" is only the first question — "can it share the data I actually need" is the one that decides whether an integration will genuinely help.

Why does custom software have an edge here?

Custom software can be built to integrate cleanly with your existing tools' APIs from the start, and to expose good ones itself. So instead of hoping two off-the-shelf products happen to connect — and discovering after you've bought them that they don't share the data you need — you get a system designed to sit neatly in your stack.

That's a real advantage when the whole point is a connected operation. A fitted system can be built to speak to your accounting software and your CRM properly, rather than leaving you to bridge whatever gaps two generic tools leave between them. It's the difference between a stack that was assembled to connect and one you're hoping will connect after the fact.

The honest first step

Whether your tools can be connected depends on what APIs they offer — which is worth knowing before you plan any integration, or even before you buy the next tool. Reviewing your stack with that lens shows what's connectable today and where the barriers are, so you're planning around reality rather than hope. You don't need to become technical to do it; you just need to ask the right plain questions of each tool.

Related reading

• •What system integration actually means (in plain English)
• •Why your business tools don't talk — and what it's costing you
• •Integrating your business systems: the complete guide

Tell us what you run, and we'll show you what's possible.