Picture a busy restaurant. You sit at your table and read the menu, but you never walk into the kitchen, and the chef never comes out to ask what you want. A waiter carries your order in and brings your meal back out. You do not need to know how the kitchen works. You just need to know what you can order and how to ask.
That waiter is an API. An API, short for Application Programming Interface, is a set of rules that lets one piece of software ask another piece of software for something and get an answer back. MDN Web Docs, Mozilla's developer reference, describes it as a contract between the program offering the API and the other software that uses it. The kitchen agrees to honour any order on the menu. The software agrees to honour any request the API allows.
For a small business, this matters for one practical reason: APIs are how your tools talk to each other without you in the middle copying and pasting. This article walks through one exchange step by step, shows what an answer actually looks like, and corrects the misunderstanding that costs buyers the most.
Requests and responses: one exchange, step by step
Almost everything an API does comes down to two moves: a request and a response. Amazon Web Services describes the roles cleanly. The software making the request is the client. The software sending the answer is the server.
Here is the full sequence when your website shows live stock levels:
- 1.A visitor opens your product page.
- 2.Your website (the client) sends a request to your inventory system (the server), asking how many of product X are left.
- 3.The request lands at a specific web address the inventory system publishes for exactly this question.
- 4.The inventory system looks up the answer in its own database.
- 5.It sends back a structured reply.
- 6.Your website reads the reply and displays 14 in stock.
The whole loop takes a fraction of a second, and no person touches it. The same pattern runs underneath most software you already use. Your phone's weather app requests today's forecast from a weather service. Your accounting software requests yesterday's transactions from your bank.
What the reply actually looks like
The reply in step five is usually a small block of labelled text in a format called JSON. Here is a realistic example of what the inventory system might send back:
{
"product_id": "TSHIRT-NAVY-M",
"name": "Navy T-Shirt (Medium)",
"in_stock": 14,
"price": 39.95,
"currency": "AUD"
}Two things are worth seeing here. First, it is readable. You can work out what it means without any training, and so can any other system. Second, every label was agreed in advance. Your website knows to look for the in_stock field because the API's documentation promised it would be there. That promise is the contract MDN describes, and it is why two systems that have never met can exchange data reliably.
Endpoints: the specific address you ask
If an API is a menu, an endpoint is a single item on it.
Postman, a widely used tool for working with APIs, defines an endpoint as the specific web address where an API receives a request and sends back a response. One API usually has many endpoints, each for a different job.
Think of a booking system's API. It might offer one endpoint to check available times, another to create a booking, and another to cancel one. Software talking to that system chooses the endpoint that matches what it needs. Asking the right endpoint the right question is most of what an integration does.
You will rarely see endpoints yourself. They sit behind the scenes. But the concept explains something practical: why two systems can connect for one task and not another. The connection only works where an endpoint exists for it. A booking tool whose API can create appointments but cannot export customer details will happily sync your calendar and quietly refuse to feed your CRM.
Why your tools need to talk
Most small businesses run on a handful of separate tools: a website, a customer database (a CRM), an email platform, a point-of-sale system, accounting software. Bought separately, they do not know each other exists. The owner becomes the integration layer, retyping the same information from one screen into the next.
APIs remove that job. A few patterns we see constantly in our work:
- Website to CRM. A new enquiry on your contact form is sent straight into your CRM as a lead, tagged and assigned, with no manual entry.
- Point-of-sale to accounting. Each sale at the counter flows into your accounting software as a transaction, so your books stay current without a weekly data-entry session.
- Booking system to calendar. A customer books online and the appointment appears in your calendar, with a confirmation email sent automatically.
In every case the principle is the same. One system makes a request, another responds, and a task that used to need a person now runs on its own. This is the foundation under most of the LLM-powered automations we build, because an AI tool is only as useful as the systems it can reach.
A close relative worth knowing is the webhook. An API waits to be asked. A webhook does the opposite: it announces the moment something happens, so the receiving system can act at once. The two are often used together, and we cover the distinction in Understanding Webhooks.
An API is the socket, not the cable
Here is the wrong belief we correct most often. An owner buys two tools, confirms both have APIs, and expects them to start sharing data. Nothing happens, and the conclusion is that one of the tools is broken.
Neither is. An API makes a connection possible; it does not make the connection. Someone still has to build the integration: a small piece of software, or a workflow in a no-code platform such as Zapier or Make, that calls one tool's endpoints, reshapes the answer, and passes it to the other tool's endpoints.
So the correct model has three parts, not two. Tool A offers endpoints. Tool B offers endpoints. Between them sits an integration that does the asking and the telling. When a salesperson says their product integrates with everything, the accurate translation is usually that it has an API, so integrations can be built. The gap between those two sentences is where budgets get surprised, because the building is a real piece of work, even if a small one.
REST, in one minute
If you read software documentation, one term comes up more than any other: REST.
REST is the most common style for web APIs. Red Hat describes it not as a strict standard but as a set of design principles for how a client and server should talk over the web. AWS notes that REST APIs are the most popular and flexible kind in use today.
You do not need the technical detail. What matters is that REST is a shared convention, and JSON, the labelled text you saw earlier, is its usual reply format. When two systems both follow the convention, connecting them is faster and cheaper, because developers work with a familiar pattern rather than inventing one. When a product says it offers a REST API, it is signalling that it speaks a language most other modern tools already understand.
Do this now: check whether your software can join
You can test the most important tool in your business against this article in about ten minutes.
- 1.Pick the tool your business would hurt most without: your booking system, CRM, or point-of-sale.
- 2.Search the web for its name plus API documentation. Established products such as Xero, Shopify and Square publish theirs openly.
- 3.If documentation exists, skim the list of endpoints. You are looking for the actions you would want automated, worded as verbs: create a customer, list orders, export invoices.
- 4.Check the vendor's pricing page for API access. Some products only include it on higher plans, which changes the real cost of the tool.
- 5.If you find no documentation at all, treat that as your answer. The tool is an island.
Expect one of two results. Either you find a documented list of actions, which means the tool can join the rest of your business, or you find silence, which means every future automation will have to route around it. Either way, you now know something most buyers never check.
How we use APIs at Enki
We treat APIs as the connective tissue of a business. The aim is rarely to add another tool. It is to make the tools you have act as one system, so information moves on its own and your team stops being the manual bridge between screens.
Our Lead Management System build is this idea in practice. Enquiries that were once handled by hand across disconnected tools now flow through connected systems, a change that saved the client more than 1,500 hours a month and generates its reports automatically. None of it required ripping anything out. It required getting the pieces to talk. As AI assistants take on more of this connecting work directly, through emerging standards like the Model Context Protocol, that connective layer only becomes more valuable. The businesses that win with software are not the ones with the most tools. They are the ones whose tools talk to each other.