APIs: how your software talks to other systems
Every application is connected to others. What an API is in plain terms, how the conversation works, and what to ask before relying on one.
The short answer
No modern application stands alone. It takes payments through one service, sends email through another, checks addresses with a third, posts invoices to the accounting system and asks an AI model to summarise a document. Each of those conversations happens through an API: a documented set of requests one system accepts from another, and the responses it returns. Your software uses other systems’ APIs so that it does not rebuild what already exists, and it offers its own API so that other systems, and your future self, can use what it holds. Well-built software treats every external API as something that will be slow, unavailable or changed one day, and is designed to keep working when that happens.
How the conversation works
| Step | What happens | Example |
|---|---|---|
| Request | Your system sends a message to a specific address with a specific shape and credentials | ”Create an invoice for customer 4821 with these lines”, signed with your key |
| Processing | The other system checks the credentials, validates the request, does the work | The accounting system creates the invoice |
| Response | It returns a result: success with details, or an error with a reason | ”Invoice 2026-0412 created” or “customer not found” |
| Handling | Your system records the result, retries on temporary failures, alerts on permanent ones | The order is marked invoiced, or a person is told the customer needs fixing |
What to ask before relying on an API
- Is it documented and versioned, with a published policy on changes and deprecation?
- What are the limits: requests per minute, per day, size of payloads?
- What does it cost at your volume, and what changes the price?
- What happens when it is down: is there a status page, and can your process wait or queue?
- How are credentials issued and scoped, and can you revoke them?
- Can you get your data out in a usable form if you leave?
- Does it support idempotency, so a retry does not duplicate an action?
Your own API
Software built with its own API from the start can be connected to reporting tools, a customer portal, a website, an automation platform or a partner’s system without a rebuild. It also forces good structure: functions that are available through an API are functions that are clearly defined. The cost is small during the build and large to add later, when the only way to get data out has become a person exporting files by hand.
What this means for you
APIs are how your software gains capabilities it should not rebuild and how it shares what it holds. Choose providers whose APIs are documented, versioned and limited in known ways. Insist that integrations are built to survive slowness, outages and changes. And make sure your own software offers an API, so the next system that needs its data does not need a spreadsheet and a person.
Frequently asked questions
Is an API the same as an integration?
The API is the door another system offers; the integration is the code you write to use it well: mapping data, handling errors, retrying, logging, keeping up with changes. A system having an API means a connection is possible. The integration is what makes it reliable.
Should our own software have an API?
If anything else will ever need its data or functions, yes, and something usually will: a reporting tool, a website, a partner, an automation. Designing the software so its own functions are available through an API from the start costs little and prevents the later situation where the only way to get data out is a person exporting spreadsheets.
What happens when a provider changes their API?
Good providers version their APIs and announce changes months ahead. Your integration continues on the old version until it is updated, which is a planned task. Poor providers change without notice and integrations break. Choosing providers with versioned, documented APIs and a change policy is part of choosing the provider.
Sources
- MDN: Introduction to web APIs (accessed 2026-09-12)