Ninety Days for a Breaking Change
How long is enough notice, and why the changelog is not sufficient warning on its own.
Ninety days is our commitment for anything that breaks existing integrations. It sounds generous until you consider how integrations are actually maintained.
Most Integrations Have No Owner
The person who wrote it has changed team or company. It works, so nobody looks at it. The realistic minimum for someone to notice, find budget, make the change and deploy it is closer to a quarter than a fortnight.
The Changelog Is Not Notice
Publishing to a page nobody subscribes to is not communication. We email every account with traffic on an affected endpoint, which requires knowing who those accounts are — that is the actual work, and it is why many providers skip it.
Never in a Patch
A breaking change in a patch release is the single most damaging thing an API provider can do, because it defeats the version pinning your users correctly put in place. Semantic versioning is a promise, and honouring it only when convenient is worse than not claiming it.
Deprecation Is Not Removal
Announcing a deprecation starts a clock; it does not switch anything off. Ours stay functional for at least two minor versions after announcement. The clearest signal you can send is a deprecation header in the response itself, which reaches the code rather than the inbox.
