Deprecating an API endpoint with Deprecation and Sunset headers

Goal

Retire an endpoint or version without surprising clients, giving automated consumers a machine-readable signal and humans a place to read about the replacement.

Prerequisites

A replacement (or a decision that none is needed), a removal date, and request logs that identify clients (client ID or user agent).

Steps

1. Decide the timeline: announcement, deprecation date, sunset date, with a period long enough for clients' release cycles.
2. Add Deprecation: @<unix-timestamp> (RFC 9745 uses a date in the structured field form) to every response of the deprecated resource from the deprecation date, and Link: <docs>; rel="deprecation" to the explanation.
3. Add Sunset: <HTTP-date> (RFC 8594) with the removal date and Link: ...; rel="sunset".
4. Document the change in the changelog and the OpenAPI description (deprecated: true).
5. Log calls to the deprecated resource by client and contact the remaining callers as the date approaches.
6. On the sunset date, return 410 Gone with a problem details body pointing to the replacement; keep that response for a long time.

Expected result

Clients that watch headers migrate on their own; the operator knows who has not, and removal is uneventful.

Limits and test basis

Headers help only clients that read them; announcement channels still matter. The header semantics follow the cited RFCs; adoption levels are not claimed.