APIs Are Contracts
Why does an integration that worked for months break the week a vendor says nothing changed?
The idea
An API defines how software systems request and return information.
In the real world
A checkout page asks a payment service to authorize a card.
Going deeper
An interface has two layers: what is documented, and what happens to be true today. Field order, an undocumented extra key, how long a response takes, the exact wording of an error — none of it was promised, and all of it is easy to build on without noticing.
This is why versioning exists. A provider who changes documented behaviour without a version bump has broken a promise; one who changes undocumented behaviour has not, however inconvenient it is. When an integration breaks after a release described as safe, the useful question is not who is at fault but which layer you were depending on.
Where it stops applying
Internal APIs inside one team are often better kept loose — the ceremony of strict versioning costs more than it saves when both sides ship together. The discipline matters most across a boundary you do not control.
Why it matters
It tells you which parts of someone else's system you are allowed to depend on, and which parts will move without warning.
Try this today
Define inputs, outputs, and failure cases before integrating.
Test yourself
Your import has run cleanly for six months. The vendor ships an update they describe as non-breaking, and your import starts silently dropping records. What did you depend on?
Show the answer
Something outside the agreed contract: field order, an undocumented field, a specific error string, or response timing. A contract only covers what both sides committed to; anything else you relied on was a coincidence that finally ended.
Learn this in the feed Answering from memory, then again days later, is what makes it stick.