# The right way to turn off your old APIs

DevFeed: [The right way to turn off your old APIs](<https://devfeed.tech/articles/the-right-way-to-turn-off-your-old-apis-19068.md>)

Original publisher: [Read original article](<https://httptoolkit.com/blog/how-to-turn-off-your-old-apis/>)

Author: HTTP Toolkit; Tim Perry

Published: 2021-01-21T10:30:00Z

Content type: tutorial

Language: en

Sources: [HTTP Toolkit](<https://devfeed.tech/sources/http-toolkit.md>)

Topics: [API](<https://devfeed.tech/topics/api.md>), [HTTP](<https://devfeed.tech/topics/http.md>), [Internet Engineering Task Force (IETF)](<https://devfeed.tech/topics/ietf.md>), [Logging](<https://devfeed.tech/topics/logging.md>), [stripe](<https://devfeed.tech/topics/stripe.md>)

Tags: [api-metrics](<https://devfeed.tech/tags/api-metrics.md>), [apis](<https://devfeed.tech/tags/apis.md>), [http](<https://devfeed.tech/tags/http.md>), [ietf](<https://devfeed.tech/tags/ietf.md>), [logging](<https://devfeed.tech/tags/logging.md>), [standards](<https://devfeed.tech/tags/standards.md>), [stripe](<https://devfeed.tech/tags/stripe.md>)

## AI overview

This tutorial explains how to safely shut down old HTTP APIs. It recommends checking usage through metrics or logging, considering internal translation to newer APIs, and creating a deprecation plan when continued support is impractical. It also discusses two draft headers from the IETF Building Blocks for HTTP APIs working group.

## Source excerpt

All things come to an end, even HTTP APIs. However great your API may be today, one day you'll want to release a completely new version, an improved but incompatible endpoint, a new parameter that solves the same problem better, or to shut down your API entirely. Your current API will not be live forever. Inconveniently though, your API has clients. If you shut down endpoints, parameters, or entire APIs without properly warning them then they're going to be very unhappy. How do you shut down your APIs safely, making it at easy as possible for your users? There are right ways to do this, including two new draft headers being standardized by the exciting new IETF "Building Blocks for HTTP APIs" working group, designed to help with this exact process. Let's take a look. Make a plan First up: check if the API in question actually has any clients. Hopefully you have some API metrics or at least logging somewhere. If you don't, add some! If you do, and you can tell for sure that nobody is using this API anymore, then you win. Turn it off right now, delete the code, skip this article and have a well-deserved nap. The next question, if you're not napping, is to ask yourself whether there's an alternative to shutting down this API. Everything you turn off will break somebody's code and take their time to fix it. It's good for the health of your client ecosystem and the web as a whole if APIs keep working. In many cases, old APIs can be translated internally, to transparently transform requests into calls to a new API instead, without maintaining two completely independent versions. This is a fundamental part of the API versioning approach at Stripe who include transformations with all API changes to ensure that requests for incompatible old versions continue to work as before, automatically translating the requests and responses to use the newer code as required. Translation like this isn't always possible, and doing so forever can entail significant extra complexity, but if