On June 13, Netflix's VP of Edge Engineering, Daniel Jacobson, sent the following letter to the service's third-party developers:
Netflix API Developers,As Netflix continues to grow internationally, the emphasis of our engineering efforts is to satisfy a growing member base and a growing number of devices. To better focus our efforts and to align them with the needs of our global member base, we will be retiring the public API program. Effective on November 14, 2014, public API developers will no longer be able to access Netflix content. All requests to the public API will return 404 errors.Thank you to for participating in the ecosystem throughout the years.Daniel Jacobson
VP of Edge Engineering
Jacobson then followed up with a post on the Netflix developer blog, repeating the same sentiments and bringing finality to an API program that had existed for six years.
As news, this was both big and small. Small, because the closure of Netflix's API program was long hinted at, and therefore unsurprising. Big, though, because the closure makes Netflix the latest of the big tech companies and services to have closed their public APIs, effectively ending their relationships with third-party developers. Twitter did it. So did Flickr. So did Google.
APIs — application programming interfaces — are, essentially, a way for companies and developers to talk to each other and build off of each other. They're a means of converting the information a service contains into the stuff of the wider Internet.
As Alexis Madrigal explained it a few years ago, "APIs allow data to be pulled from an online source in a structured way. So, Twitter has an API that lets app developers create software that can display your Twitter feed in ways that the company itself did not develop. Developers make a call to that API to 'GET statuses/home timeline' and Twitter sends back 'the 20 most recent statuses' for a user."
APIs are enablers of remix culture, essentially. And what they mix is structured data.
Because of all that, APIs have been seen, traditionally, as symbolic and practical.
Sure, they're about creating products that people will like, and use, and find valuable — products, in other words, that will be monetizable. (Use Tweetdeck or Tweetbot? Those were built, originally, on the Twitter API.) But the interfaces, the mere fact of their existence, have also been about respecting, almost literally, the webbiness of the web — as a network. As an ecosystem. As a grand, crazy, nerdy collaboration.
So it's hard not to see the closure of the Netflix API, on top of the closure of all the other APIs, as symbolic in its own way — of a new era of the web that is less concerned with outreach, and more concerned with consolidation. A web controlled by companies that prefer their own way of doing things, without external input. A web that takes the productive enthusiasms of independent developers and says, essentially, "Thanks, but no thanks."
Many developers — most developers — have long adopted this more cynical view of the API. As the blog and podcasting pioneer Dave Winer put it in a 2012 blog post about changes to Twitter's API guidelines:
Smart developers will not just conclude that Twitter is unsafe to build on, but also any company that is operating in the Twitter model. If they are running a website, and trying to attract a lot of users, and are going in the direction of advertising, you’d be a fool to think they won’t do the same as Twitter has.
Netflix, according to its blog post on the API closure, is incorporating the products it likes into its service. It's abandoning the others. And you can't necessarily fault it for doing that. As Kin Lane points out on his blog API Evangelist, the applications that came out of Netflix's particular API program weren't, overall, that good. And there weren't that many of them trying to be good in the first place. That may be because Netflix deals with licensed content, as opposed to user-generated information.
But it may also be because the constant threat of a closed API — the constant threat of Netflix doing precisely what it has now done — has created just what you'd expect it to: a chilling effect. Products built on APIs are houses built on sand — specks controlled, in the end, by the whims of the larger company. A company that is free to tell you, with much finality but little apology, "Thank you to for participating in the ecosystem throughout the years."