An API is an agreed way for software to use another application’s functions or data. Your ordering app might use one to check stock without becoming an inventory system itself. Our custom software guide explains how these parts fit into an application. For the work involved in connecting systems, see commissioning an API integration and our guide to connecting business software.
What does API actually mean?
API stands for Application Programming Interface. Think of it as an agreed entrance for software: these are the questions you can ask, this is what you must send, and this is how the answer comes back. Cloudflare explains how programs use each other’s functions in this way.
An API isn’t a particular type of database. Nor is it necessarily a screen that staff work in. A user sees an availability message, for example, while the app requests that information in the background.
APIs also exist within software and operating systems. MDN distinguishes browser functions from APIs supplied by external services. In a business software discussion, a supplier saying “the API” often means a web interface through which other systems can request data or perform actions.
How does an API work in a familiar example?
Imagine an employee selects an item in an ordering app. The app asks an inventory system whether it’s available. The inventory system answers, and the app displays the result. This is a simplified hypothetical example, not a client case study.
The question is called a request. The answer is a response. The app sends its request to the relevant API address, called an endpoint. MDN’s introduction to network requests explains how software receives a response and checks whether the request succeeded.
What the employee can do next is a separate decision. Checking stock isn’t the same as reserving it. The API may allow both, or just the first. “It has an API” doesn’t settle that question.
The meaning of the answer needs to be clear too. Does “available” mean everything in the warehouse, or only the stock that hasn’t already been promised to another customer? An answer can be technically correct and still mean the wrong thing to the employee. Ask the supplier to work through the example using the terms your team uses.
Which terms will you see in a proposal?
The terms below describe different parts of the same exchange. You don’t have to build them yourself, but understanding them makes a proposal easier to assess.
| Term | Meaning in the example | A useful question |
|---|---|---|
| API | The interface offered by the inventory system | Which functions are available? |
| Endpoint | The address for a particular request or action | Is the stock enquiry documented? |
| Request | The ordering app’s question | Which product identifier must it send? |
| Response | The inventory system’s answer | Which stock status comes back? |
| API key or token | An access credential, depending on the service | What may the ordering app do? |
| Documentation | Instructions for the developer using the interface | Are examples and errors explained? |
A link to an API in a quotation doesn’t tell you much on its own. You need to know which action it supports and what the result means for your process. Ask for a short demonstration using a recognisable item or record. That makes it much easier to tell whether you’re discussing the same thing.
What’s the difference between an API and an integration?
The API offers a capability; an integration uses it in a working process. Think of an entrance and the route you take through it. Having an entrance doesn’t make information arrive at the right destination at the right time.
In the stock example, someone must decide when the ordering app checks availability, how product identifiers match and what message appears when there’s no answer. Those decisions belong to the integration and the application around it.
The systems don’t all need to offer the same API. An application can call another system’s API. What each side can do must fit the action you need, though. An app that only displays information has different requirements from a process that writes changes back.
The type of product is a separate choice. A web app, SaaS product or custom platform can all use APIs. Having an API doesn’t tell you whether a package suits your whole business.
Does an open API mean anyone can access it?
No. “Open” can mean that the interface is intended for external developers or has public documentation. It doesn’t make all the data public. Ask the provider what they mean by the term.
Some APIs are intended for internal use, some for approved partners and others for a wider audience. There are also technical approaches such as REST and SOAP. These classifications answer different questions: who may use the interface, and how is communication arranged?
What matters to you is what your account may do. A credential that can read stock levels needn’t be able to change customer records. GitHub’s API security guidance includes restricting permissions and keeping secret credentials out of public code. Ask your supplier how keys are stored, replaced and revoked.
Don’t include a secret API key in a general request for a quote or a screenshot. You can discuss the access needed without sharing the credential itself.
How does an API request differ from a webhook?
With a normal request, your software asks for information. A webhook lets the other side send a message when an agreed event happens. GitHub explains the distinction as periodically checking for changes versus receiving an event notification.
In our example, the app could check stock when an employee opens an item. If the inventory system offers suitable webhooks, a stock change could also trigger a message to the app. Whether you need that depends on the work. A daily report may tolerate older information than a reservation made during an order.
A webhook doesn’t promise that an entire process will always finish correctly. The receiving software still has to handle the message. Ask which point the employee sees on screen: the message being sent, its receipt, or the change actually being saved.
What happens if a request fails?
That depends on the failure and the arrangements you’ve made. An unknown product identifier needs a different response from a temporary connection problem. In either case, the employee needs a useful message, but the underlying fix differs.
Trying again sounds simple. For an action that creates something, a retry could produce a duplicate if the first request was processed but its response was lost. Stripe describes idempotency keys as a way to recognise those repeated requests safely. That’s a feature offered by one provider, not something you should assume every API has.
So ask a demonstration to include what the user sees when a response doesn’t arrive. Should they wait, click again or ask an administrator to take over? That discussion is more useful than simply asking whether the connection is “real time”.
What should you ask before choosing software?
Start with the action you need. “Check stock for the ordering app” can be demonstrated. “A modern API” is much harder to assess. Compare what your team expects with what the supplier actually makes available.
Ask whether the function is included in your subscription, what usage limits apply and who announces changes. An API may have separate terms. Find out who handles the work when a provider retires an old version: the software supplier, your developer or both.
For custom software, these arrangements belong in the handover. Who manages access, where is the documentation, and could another developer take over? Our guide to code ownership and supplier dependence helps turn those questions into clear agreements. The API is only one part of that handover.
How do you actually get started?
Write down one example: who takes an action, what information do they need, and which system holds it? Then ask the supplier to demonstrate that exact route, including the response when something goes wrong.
If it needs a separate application, you can commission custom software around the process. With TopDevs, the code is and remains yours. Start with the question the software must answer; the technical design follows from what that requires. Book a call.
