This is all great advise. I feel like there is one important detail missing. There is no way to turn off an API like this without guaranteeing not to introduce

This is all great advise. I feel like there is one important detail missing. There is no way to turn off an API like this without guaranteeing not to introduce breakage. Even for a well behaved client that has enough foresight to anticipates API deprecation. You only get the specified headers AFTER calling the API endpoint. So for example if a device sits in a drawer for a year, then calls the API your response is undefined if the API has been turned off. No chance to get the date beforehand. The way I handled situations like this is to explicitly make 'turned off' part of every single API response. Something like APIResponse = SpecificResponseForEndpoint | TurnedOff That way API interactions are always well defined, clients can implement a global handler that does the appropriate thing, locking the client in a 'please update' state if it is an in house developed app for example. For HTTP I usually reserve the 410 status code for that since it usually does not collide with the more common 404.