Sunset

Versioning & Lifecycle IANA permanent response reached by regulation 2 spellings

Sunset carries a single HTTP date: the moment after which the resource is expected to become unresponsive. It is the companion to Deprecation, and it answers the only question that actually drives migration work — not “is this going away” but “by when”.

Six providers in the catalog declare it. In regulated contexts this is stranger than it looks: the Australian Consumer Data Standards run published retirement schedules, and the PSD2 RTS obliges banks to give third parties notice and a testing window before interface changes. Those are legal obligations to communicate a date, being met everywhere except the one place a machine could read it.

The registry

Listed in the IANA HTTP Field Name Registry as a permanent entry. Defined in RFC 8594: The Sunset HTTP Header Field.

In the catalog

Declared by 6 providers across 787 published specification files in the API Evangelist catalog, where it appears as a response header — sent by the server.

It is spelled 2 different ways across those contracts — sunset, Sunset. HTTP field names are case-insensitive (RFC 9110, §5.1), so every one of these is the same header. They are not the same string, which is why generated clients disagree about it.

Reached by regulation

No law names this header. It is evidentiary — the deployed control for an obligation that regulation does impose. It is observable at the edge: an unauthenticated request is enough to see whether a provider sends it.

Using it

An HTTP date, always in the future when you first send it. Keep sending it right up to the shutdown — a client that integrates the week before cutover deserves the same warning as one that integrated a year out. Do not remove the header when the date passes; remove the resource.