![](https://s3.amazonaws.com/kinlane-productions2/bw-icons/bw-skull-crossbones.png)
I had one of my followers ask me if there as a “gold standard for API deprecation policies” out there. I’d say that deprecation policies are a little different than some of the other legal building blocks of an API, where the legal is a small portion of it, with the majority really being all about communication.
To answer the question, I recommended Google. Not cause their deprecation policy itself is all the great, it is just because their overall approach to API deprecation is pretty robust—something I’m sure is derived from their experience so far. (wink wink)
API deprecation at Google starts with some pretty clearly stated policies, but goes much further with:
These are just a handful of the building blocks that Google employs as part of their approach to API documentation. This post is just result of a 15 minutes of Googling around, to respond to the question. Now that I have written this post, and put the topic of API deprecation back on my radar, the next step is to dive deeper and develop a complete picture of how Google approaches API deprecation, as well as other leading players in the space.
At first take, it appears to me that the legal details of API deprecation that are present in terms of use, or as standalone documents is only the start. The winning examples of API deprecation involve making sure deprecation details are always readily available, regularly communicated, and are comprehensive enough to cover the API, data, and other things that matter to developers and end-users.