Netflix Closing Public API Later this Year

The number of public APIs continues to grow by leaps and bounds, but later this year developers will lose access to a popular API. Yesterday, streaming video giant Netflix announced it will be shuttering its public API on November 14, 2014.

Launched in late 2008, the Netflix API, which comes in JavaScript and REST flavors, gives developers the ability to browse and search its extensive content catalog, retrieve user ratings, manage user queues and initiate Play buttons into their applications.

"The API program has shifted over the past few years to support our growing and evolving streaming business. Its primary focus is to support the myriad devices used by our 33 million members to stream TV shows and movies from Netflix. Because of this evolution, we are making additional changes to the public API program."

Netflix says that “a small set of developers whose applications have proven to be the most valuable for many of our members” will continue to have access to Netflix once the public API is retired. These developers include Flixster, Fanhattan and Instant Watcher.

Effective immediately, Netflix has stopped issuing new public API keys to developers and is no longer accepting API affiliates. It is also putting the message boards on its developer portal into read-only mode.

A decision years in the making

While some developers are likely disappointed by Netflix’s announcement, the company’s decision to retire its public API is one that didn’t come out of the blue.

In a May 2012 ProgrammableWebguest post, Daniel Jacobson, Netflix’s director of engineering for the Netflix API, discussed the problems associated with the one-size-fits-all approach many companies take when implementing REST APIs. “The potential shortcomings surface because this model assumes that a key goal of these APIs is to serve a large number of known and unknown developers,” he wrote. “The more I talk to people about APIs, however, the clearer it is that public APIs are waning in popularity and business opportunity and that the internal use case is the wave of the future.”

Jacobson further explained,

"The potential conflict between the internal and public use cases is in the design of the API itself. Keep in mind that the design implications will not be problematic in many scenarios. It becomes a potential problem if the breadth of devices becomes so wide that the variability of features across them becomes substantially harder to manage. It is the breadth of devices that creates a problem for the one-size-fits-all API solutions."

Jacobson brought this issue up again and expanded on how Netflix’s approach to its API was evolving in another guest blog post late last year. While Jacobson’s posts lacked an explicit statement about the retirement of Netflix’s public API, in retrospect it is evident that Netflix’s approach was leading the company in a direction that would create tension between the API that its “small set of known developers” needed and those that its “unknown developers” were already using.

Is the golden age of public APIs over?

Of course, Netflix isn’t the first company to determine that it had to change the rules of engagement with its developer ecosystem. Another online powerhouse with a popular API, Twitter, was forced to make significant changes to its public API when it became clear that the company’s business model would require it to exert more control over the way users interacted with its service. That meant there was little to no room for developers who had used Twitter’s API to build their own Twitter clients.

Pointing to Twitter and now Netflix, some might ask if the golden age of public APIs is over. After all, if prominent companies with popular APIs are willing to make drastic changes to them or shut them down completely, can developers trust that the public APIs they use today will be available, or available under the same terms, tomorrow? That’s a difficult question to answer, but needless to say, developers should always consider the risks associated with their reliance on third-party APIs.

They should also consider the nature of the public APIs that they build on. The number of companies that are being built around an API-based offering continues to grow. At least in principle, these types of companies have every reason to support those APIs because the API is their product. The Netflix public API was never a core product for Netflix and while APIs are critical to its business, continuing to making those APIs available to the public simply isn’t.