What is an API?
An API is a contract between two systems. One side publishes a list of operations, states what each one accepts and what it returns, and commits to keeping that behaviour stable. The other side calls those operations without knowing how they are implemented, and without needing access to any code or database.
The word describes the agreement, not the technology. HTTP requests returning JSON are the common form today, but the same idea covers a query language, a message queue or a library call. What makes something an API is that the behaviour is declared and stable, not the transport it travels over.
That framing matters because it moves the important questions out of the technical column. Whether a system has an API is rarely interesting. What the API exposes, what it withholds, what it costs and how long it stays unchanged decide whether an integration is a two-week job or a permanent liability.
Why APIs matter
For a company buying or building software, four consequences follow directly.
- An API decides whether you can leave. A product whose data is reachable only through a manual export is a product that will be expensive to replace. The presence of a documented API, and the completeness of what it exposes, is the practical measure of vendor lock-in. It deserves a place in the purchase decision, not in the technical appendix.
- It removes duplicate data entry between systems. The reason a customer address gets typed into three tools is almost never that connecting them was impossible. It is that nobody scoped the connection.
- It makes automation possible without replacing anything. Connecting two systems that each do their job well is usually far cheaper than migrating to a single suite that does both adequately.
- It is now a legal necessity in some cases. Structured e-invoicing in Belgium requires invoices to leave and enter systems as machine-readable data. That path runs through an interface, whether it is called an API or an access point.
The uncomfortable counterpart is that an integration is never finished. The other side of the contract belongs to somebody else, who will change a field, deprecate a version or tighten a rate limit on their schedule rather than yours. Budgeting an integration as a one-off project is the single most common planning error, and it surfaces six months later as an urgent fix nobody allocated time for.
How it works
Five mechanisms cover almost everything worth understanding as a buyer.
Request and response. The consumer sends a request naming an operation and its parameters. The provider returns a structured answer, plus a status indicating success or the reason for failure. Handling the failure cases properly is most of the work.
Authentication. Every call proves who is making it, usually with a key or a token, and the credentials carry a scope. A well designed integration receives the narrowest access that lets it work, which is what prevents a compromised key from becoming a full breach.
Rate limits. Providers cap how many calls you may make per minute or per day. This is a functional constraint, not a detail: an integration designed without knowing the limit will work in testing and fail on the first busy day.
Versioning. A provider that changes behaviour breaks every consumer. Serious providers publish versions and a deprecation policy stating how much notice you get. Providers without one will eventually break your integration with no warning, and that risk belongs in the evaluation.
Webhooks. The reverse direction. Instead of your system asking every few minutes whether anything changed, the provider notifies you when it does. Cheaper, faster and less fragile than polling, and its absence usually means a queue of scheduled jobs nobody wants to maintain.
Implementation
The list below is written as questions to ask before signing, because that is when the answers still change the outcome.
- Is the documentation public, and can you read it before buying? Documentation available only after signature is a warning, not an administrative detail.
- Is API access included, or is it an upgrade? Selling the interface separately is common and legitimate. Discovering it after signing the main contract is not a good position.
- Does it expose everything you need to leave with? Read access to your own historical data matters more than the fashionable endpoints. Test one real export before committing.
- What is the rate limit, and does it fit your peak? Not your average. Month-end and season peaks are where limits bite.
- What is the deprecation policy? Ninety days of notice and a changelog is a workable answer. No policy at all means your integration is scheduled to break at a time chosen by somebody else.
- Are webhooks available? Their absence forces polling, which costs more, reacts slower and adds jobs to maintain.
- Budget maintenance, not just delivery. An integration is a subscription to somebody else's roadmap. Plan a small recurring allowance rather than an emergency.
Related technologies and tools
- REST and GraphQL: the two dominant styles. REST exposes fixed operations, GraphQL lets the consumer specify exactly which fields it wants. The choice affects effort, not capability.
- OpenAPI: the standard for describing an interface in a machine-readable file, from which documentation and client code can be generated. Its presence is a good proxy for how seriously a provider treats the contract.
- Webhooks: provider-initiated notifications that remove the need to poll for changes.
- OAuth 2.0: the standard for delegated authorisation, which lets an integration act on a user's behalf without holding their password.
- API gateways: the layer that centralises authentication, rate limiting and logging in front of several interfaces.
- MCP: the emerging standard for exposing tools and data to language models, which sits on top of existing APIs rather than replacing them.
Conclusion
An API is a commercial commitment expressed in technical terms. Judge it the way you would judge any supplier commitment: what is promised, what it costs, what notice you get before it changes, and what you can take with you if you leave.
The question worth asking before a software purchase is therefore not whether the product has an API. It is what the API lets you leave with. A vendor who answers that clearly and lets you test one real export is offering a different kind of relationship from one who treats the interface as a premium feature. That difference costs nothing to check and a great deal to discover late.
