2015: API Deprecation and Versioning Now a More Strategic Issue

But when Twitter gives with one hand, it takes with the other. Shortly after pleading with developers to start a relationship with Twitter afresh, Twitter’s VP of Data Products Chris Moody announced a new API suite based off their firehose API, now being managed by another Twitter ecosystem partner-turned-acquisition Gnip. While that move was part of a longer term vision for Twitter, the move came at almost the same time as when Twitter would be removing right of access to the firehose API for other partners, like DataSift, who had used Twitter’s API to build a large data analytics company. (DataSift's firehose contract had been terminated in April, but access was finally switched off in August, and the new firehose APIs were released in October.) While DataSift has been quick to reorient their market position, it is a stark example of the way an API can break a whole business model.

Two views on the changes to Twitter's API terms of service

The move garnered a range of opinions: 3scale CEO Steven Willmott argued that the deprecation would stifle Twitter’s capacity to use network effects to drive innovation. Klout's director of platform Tyler Singletary, counterbalanced with a view that we will probably see that this move was part of a broader realignment of how Twitter sees its platform business model as operating. Similar reactions both for and against were made by developers on Hacker News, although a lot more developers were still angry at Twitter’s trust issues, common reactions included:

  • “Yeah, until they revert this change, it doesn't matter and to be honest I doubt developers even care about Twitter anymore. I certainly don’t.”
  • “… its backstabbing developers who are popularizing Twitter in their own way.”

Deprecating APIs in 2015

The closing end of 2014 saw deprecation of APIs begin to become more a standard part of the API economy, with early API leaders like ESPN and Netflix deprecating their APIs.

In 2015, the strategy of deprecating APIs grew even more common.


Asana alerted users to their API key deprecation in August, spelling out a clear timeline for complete closure and providing a migration mechanism to their preferred alternative, OAuth authorization. The deprecation was sited for reasons of security and that the API provided a “degraded user experience overall”.


In April, Dropbox announced the release of a new Dropbox API v2, and along with that were deprecating their Sync and Datastore APIs. Their Datastore API had been an experiment in providing a sort-of API-as-a-database-service product: data stored in a user’s Dropbox folder could be accessed directly via the Datastore API. It had not seen the sort of uptake that Dropbox had hoped for, so they were discontinuing it. The Sync API features were incorporated into the v1 Core API, but had been continued alongside that, creating SDK confusion for developers and a complex production pathway for users. With the consolidation of the Core API v2, Dropbox was discontinuing the Sync API. Support for the two APIs was discontinued in October 2015, with the Datastore API scheduled for complete deprecation in April 2016.


After announcing the deprecation of their Shopping API in 2011, eBay finally turned off the taps completely at the end of February this year. eBay offers resources including a migration guide, an API features comparison chart and a versioning strategy to explain their deprecation policies and to help developers identify which APIs they should now be using as a replacement.

See also:



In April, Facebook deprecated its Graph v1 API. To encourage developers to make the move, Facebook released a new testing tool that allowed developers to see how their app would behave under v2 of the API.

Facebook regularly deprecates its APIs as part of its versioning strategy. In October, it shut off access to v2.3 of its Facebook Marketing API in favor of v2.4. Unlike other timelines, Facebook provided three months for developers to make the switch between time of announcement of v2.4 and when v2.3 was deprecated.

See also:




As the year started, Google gave users of its Google Maps Coordinate API one year’s notice that it will be deprecated on Jan 21 2016. Users are encouraged to migrate to newer products more aligned with how Google wants to provide mapping services to businesses, primarily through its Google Maps for Work API portfolio. In July, Google also turned off API access to its undocumented Autocomplete API, saying that was never its intended use. Earlier this month, Google announced a slight reprieve for the Google Earth API, which will remain open a little longer. This API is being deprecated because of security issues in the API’s legacy technology. Google is also finally deprecating its DoubleClick Ad Exchange SOAP API in January 2016, from which users are expected to have migrated already to the REST API.

See also:




In November, Instagram announced the shutdown of its Feed API, immediately closing access to new developers. Existing applications have until June 2016 to resubmit their app and go through a review process to determine if Instagram wants to continue working with them as a preferred partner. Like Twitter’s client applications model, the Feed API enabled third party providers create their own interface for viewing Instagram feeds, but has not been proven to be a platform kickstarter in the same way that Tweetdeck was for Twitter.


In February, LinkedIn announced it would be limiting their API access from May, providing just three months notice to developers.

The move aimed to clarify the sorts of platform use cases that LinkedIn wanted to support. The move limited API access to use cases that allow end users to control how they share their profile or update their qualifications, and how they manage their own content from LinkedIn.

Alongside the restriction, LinkedIn introduced a partnership program that asks third party developers to enter a more formal commercial arrangement with LinkedIn for more expanded use of their APIs. Existing API users like Evernote, Samsung and WeChat were moved to the Partner Program immediately.


While not quite a deprecation, in June, Twitter pulled API access from government transparent watchdog Sunlight Foundation’s Politwoops product. As part of an accountability tool, Sunlight tracked all politicians’ deleted tweets and kept a public record of them. Twitter saw this as a violation of their terms of service and removed API access. In another upset for developers, Twitter closed backdoor access to an undocumented API, its Twitter share counter. While never a public API, Twitter’s tech stack move from Cassandra to Manhattan meant that developers who had been using the unofficial API would no longer have access. Although, without this access, heavier users would also now need to subscribe to one of Gnip’s paid API products.

See also:




Yelp switched off access to their API v1 in September this year. The deprecation date was extended from the original plan deadline of July. Developers were provided with a migration path, sample codes demonstrating the v2 API. v1 users were sent an email, were notified in a Google group, and via FAQ pages on the developer portal.

See also:


The API Graveyard

Meanwhile, services that had deprecated their API in 2014 became a graveyard. ESPN has removed several of their pages, although still has their API sandbox up, sadly returning “503 - Service Unavailable” responses.

Netflix’s developer portal link now sends searches to a 500 status code: No origin found for request. That even includes the blog post Daniel Jacobsen wrote about Netflix closing down its API.

Be sure to read the next Developer Relations article: 5 Steps to Running a Successful Beta Community


Comments (1)


Good article and points to the negative side of resuse in our SOA world.  It is a lot worse internally in a business because the consumers often have more power than the provider so they can invoke change radomly without the communication and SLAs  and clear expectations for the consumers.  But the stability and simplicity of using APIs is what lets so many apps be built so quickly.  I think there needs to be some flexibility on the consumer side that they will have unexpected changes and inopportune times and that's the price of a free service or one they couldn't build themselves.