An API, application programming interface, is a defined interface through which one program can use another’s functions or data. It describes which requests are possible, which details they require, and which responses come back.
An API is a contract
The most important idea is that a published API is not an implementation detail but a commitment. As soon as another system uses it, that system’s functioning depends on it. A change that looks trivial internally — a renamed field, a different data type, a stricter validation — can cause an outage for every consumer. That obligation is the real difference between an internal function and an API.
What an interface describes
An API is only fully described once four things are fixed: which operations exist, which details each operation expects, which responses it returns, and which errors can occur. The fourth is most often neglected and is in practice the most important — a calling system must know how to react to an error, and it can only do so if errors are defined and distinguishable.
Versioning
Because an API is a contract, changes need an orderly route. Additions are uncritical: a new optional field disturbs nobody. Changes to existing behaviour are not. The usual approach is versioning, keeping the old version reachable while the new one is introduced, with an announced deadline for the switch. Changing silently instead shifts the cost onto every consumer at once.
Documentation is part of the product
An interface without documentation is practically unusable, because every consumer must reconstruct its behaviour by experiment — and in doing so inevitably mistakes undocumented quirks for commitments. What is useful is documentation that, alongside the formal description, contains concrete examples of requests and responses, including error cases.
What separates a good one from a usable one
A usable API works. A good one is additionally predictable: similar operations follow the same pattern, naming is consistent, errors look the same everywhere, and behaviour on repeating the same request is defined. That predictability lowers effort on the calling side more than any additional feature.
Practical consequence
Before publishing an interface, it pays to ask whether you would still want to live with it in two years. What is published and used can only be changed with effort — and that effort falls on everyone, not only the provider.