API Deprecation

API deprecation is a provider announcing that an endpoint, a field, an authentication method or an entire API version will stop working on a stated date. From the publisher's seat it is housekeeping. From the seat of everyone who integrated against it, it is unscheduled engineering work arriving with a deadline somebody else set, and it is one of the few risks in an integration that is certain to occur rather than merely possible. How you find out is the first problem. Notices travel by changelog, by a header quietly added to responses, by an email to the address that was used to register the application — often a developer who has since left — and by a banner in a dashboard nobody logs into once the integration works. A team can be inside a sunset window for months without anyone noticing, and the first signal becomes a support ticket on the day the endpoint returns an error. The second problem is that migration cost is rarely proportional to the size of the change. Renaming a field is an afternoon. Changing an authentication method touches every credential you have stored on behalf of every customer, and usually requires each of them to click something, which makes it a customer-communication project rather than a code change. Deprecations also arrive in clusters — after an acquisition, a platform rewrite, or a security incident — so the assumption that they will be spread evenly across a year is not safe. Practical habits. Keep an inventory of every third-party API the product calls and which version it calls, because you cannot assess a deprecation notice for an API you did not know you depended on. Register integrations to a shared alias rather than an individual. Put the sunset date into the same backlog as your own roadmap the day it is announced, not the month before it lands. And treat a long support commitment as absent unless it is written into an agreement — a public deprecation policy is a statement of intent that can be revised, not a guarantee.