Actually pointed out in the document: The next question, if you're not napping, is to ask yourself is whether there's an alternative to shutting down this API.

Actually pointed out in the document: The next question, if you're not napping, is to ask yourself is 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. There are valid reasons to shut down an API (outside of "the company will shut down"). Some API shutdowns are security-wise, for example the API relies on an outdated authentication scheme that can easily be cloned or bruteforced. Assuming that you are in 2012 when credential sharing were acceptable, it's impossible to develop a backwards-compatible API because simply the method to authenticate is now vastly different (tokens versus classic username-password credentials). Some will argue "oh, just generate app passwords!" but unless your audience is that savvy enough, having the API left on will shift the burden from a one-time change to a continual cycle of explaining users to use an app password (which will hit you very badly). At other times, you need to shut down an API due to an external change. For example, separating APIs by region (note that "oh, just geodetect it" haven't really been sent up letters from a government agency in charge of data and privacy).