An API is the interface through which one program lets another program request data or trigger actions, following fixed rules. It matters to you as soon as your tools are meant to work together: website and customer management, shop and shipping, booking and calendar. If you understand what an API does, you ask the right questions before choosing software.
What is an API and how does it work?
Think of a restaurant. As a guest you see the menu and order from the waiter. You do not walk into the kitchen. The waiter carries your order there and the result back. The API is the waiter: it takes requests in a fixed pattern, passes them to the system behind it and returns the answer.
Technically, one program sends a request over the internet, usually to a web address, and receives structured data in return, often in JSON format. The basics of that communication are described in MDN's overview of HTTP. A good API has documentation explaining which requests are possible and what the answers look like.
Where do you meet APIs in everyday work?
APIs sit inside many tools you already use, even if you never see them. The table shows typical examples.
| Example | What the API does | Benefit to you |
|---|---|---|
| Payment in a shop | The shop hands the amount to the payment service and gets the result back | Customers pay securely, the order is confirmed automatically |
| Website form to CRM | The form sends contact data to customer management | No enquiry gets lost in the inbox |
| Booking and calendar | The booking tool syncs appointments with your calendar | No double bookings |
| Shipping and shop | The shop creates a shipping label with the carrier | Less manual work |
| Map services | The website shows directions on a map | Visitors find you more easily |
What do you gain if a program has an API?
An API enables connections that would otherwise be manual work. You can match data between tools automatically, automate processes and build your own extra features. It also protects against dependence: if you can retrieve your data through an interface, it is easier to move to another program later.
If a program has no API, you are often left with file exports or manual entry. That is tolerable for a few records, but a source of errors as the business grows. How systems notify each other when something happens is explained in What is a webhook?.
Which questions should you ask vendors?
Before introducing a new tool, clarify a few points. Is there a public API, and is it documented? Which data and actions does it cover? Are there limits on the number of requests, and does use cost extra? How does sign-in work, and can access be limited to certain areas? Are there notifications on changes, so-called webhooks?
Also consider data protection: if personal data is passed to a service provider, you generally need a data processing agreement. This is not legal advice.
- List of the tools that should exchange data drawn up
- Each vendor asked about a public API and documentation
- Costs and limits of API use clarified
- Access limited to the essentials, keys protected
- Data protection and data processing agreement checked
- Logs and error messages set up for critical connections
Conclusion: ask about the interface
An API is not a term for developers alone but a precondition for your tools to work together. Ask about the interface before every purchase and protect access carefully. If you want to connect your systems, see our business systems service or describe your process.
