This is a good reminder to all of us that any API key is just that: A key. A key to a lock you don't own and a lock that can be changed at any time.
I too am very disappointed and agree with the other commenter who said they are big enough that they don't have to worry about closing it. When I realized I wanted an API key they had already stopped handing them out, and now the axe falls again. I don't argue it's not within their right, it's just sad.<p>I have upwards of 1200 graded movies in another service that I used for a long time and that has a public API. Nowadays, I use trakt.tv a lot (and pay for it, because I really want it to be around, like I pay for Netflix and Spotify) and they also have a public API that I can use to write a tool and migrate/sync my movie grades there. Netflix' recommendation engine could have learned more about me in 5 seconds than it will in 5 years, and any grades I put into Netflix will never leave it.<p>Yes, I know I'm an edge case. Yes, I know it doesn't make business sense to cater to me. I still need to gripe a bit.<p>I have a custom app for managing my music too that uses the Spotify C library (wrapped in Go). I love that I was able to do that, and the day Spotify EOLs that library (and doesn't provide an alternative) is probably the day I leave their service.<p>Enough ranted. Sorry. I just like to take my data with me when I go.
> 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<p>What a sad statement, there is no need for this corporate-drone talk. "We're shutting it down because it doesn't make us money, and we think we will be better off being a closed platform" would have ringed much better, not necessarily in these words. Honesty is always appreciated.
There is something here that I really don't understand.<p>Why would they want to shut it down?<p>With something like Twitter, I get it. In order to make money off their customers' use of Twitter's free service, they need to be in control of the customers' experience (so they can do things like show ads). So they pulled this intentional bait-and-switch where they screwed over the independent developers who had made Twitter successful in the first place, but they did it because they needed to in order to make their profits.<p>The Netflix API story is different. First of all, APIs were always an additional offering: Netflix was grown on the backs of their mail-order business and third party apps that could just as well have been done via partnerships instead of open APIs. So they're at least not screwing over the one who brought them to the dance.<p>But the APIs have been a source of good will from the developer community (probably all out of proportion to the number of actual tools built using them). And the APIs are not harming Netflix's income stream in any way. (They might, in a tiny way, be helping, but I accept that this effect is negligible.) So where is the motivation to retire them?<p>Does it really cost so much to maintain the APIs? After all, they need to maintain them for Instant Watcher, Fanhattan, Yidio, NextGuide, Flixster, Can I Stream It?, FeedFliks, and Instant Watch Browser for Netflix. So it's not like they'll save the cost of keeping the APIs running. And I don't see how this can be about the cost of managing communications with the public -- if, instead of announcing that the APIs were now closing down, Netflix had announced that the primary support channel was now a public forum where users could help each other I doubt anyone would have batted an eyelash.<p>So help me out here: what is the motivation?
My comment from an earlier post:<p>I was disappointed to get that email, I have an API key and am using it for an ongoing (small) side project of mine.<p>It seems counter to everything else Netflix engineering promotes with its tech blog and open source contributions. To be so public and open on one hand, and then shut down the public API on the other seems strange.<p>Trying to cut down on third-party access to user account functions like managing queues could be understandable, but I hope there is some kind of access to basic Netflix library data. Otherwise people will just turn to custom scraping solutions to get the data anyway.
R.I.P. NetflixItNow - a weekend hackathon Greasemonkey/Chrome extension that sent you an email when user-selected movies became available for streaming (not just disc delivery).<p>Though the project was short lived, I am very sad that it is no longer possible to implement similar projects.<p>Netflix API code (very simple): <a href="https://github.com/swanson/netflix-it-now/blob/master/check_instant.rb" rel="nofollow">https://github.com/swanson/netflix-it-now/blob/master/check_...</a><p>Video demo: <a href="https://www.youtube.com/watch?v=h-zXOUsyXjA" rel="nofollow">https://www.youtube.com/watch?v=h-zXOUsyXjA</a><p>Entire repo: <a href="https://github.com/swanson/netflix-it-now" rel="nofollow">https://github.com/swanson/netflix-it-now</a>
This just means more people will rely on covertly scraping their data. It also means, much like Twitter and the way they nerfed their developer ecosystem, Netflix will gain much more control over any available 3rd party offerings (as they've clearly outlined). Seems like a very short-sighted trade off if you ask me, but, hey, maybe the public API was just underused and they didn't want to devote more resources to maintaining it.
Sadly, this marks the end of an era for me with Netflix. After an initial 'meh' experience with the DVD rental service when they first debuted, one of the things that really got my attention with them was their developer contest to create a better suggestion service. But it seems that working with the developer community now is a thing of the past for them. Sadly, I foresee more companies going that way.
"Thank you to all of the developers who have participated in the ecosystem throughout the years."<p>I'm not sure "thank" is the word they wanted.
When business schools a few dozen years hence discuss this period of API development, they'll talk of how we learned to use an open API as a weapon wielded by a mid-size company to fend off competitors until the company has grown to a place of market dominance.
I worked for Netflix in 2009 and 2010, first documenting the consumer API and helping out with things like oAuth, and later working on the original iPhone and Android apps, which ran inside a Web view using nothing but HTML, CSS, JavaScript, and the consumer API. (The morbidly curious should see "Mistakes I Made Building Netflix for the iPhone," at <a href="http://www.slideshare.net/kentbrew/mistakes-i-made-building-netflix-for-the-iphone." rel="nofollow">http://www.slideshare.net/kentbrew/mistakes-i-made-building-...</a>)<p>At the time, Netflix didn't run on an API; the API had been retro-fitted onto Netflix. Even a simple thing like "please tell me the availability of all the discs in this season of this television series" took several calls and a fair amount of head scratching to accomplish. Every new device that came along got a slightly different version of the API, support was terribly difficult, and when we launched for PS3, Wii, iPhone, and Android, it became obvious that our own apps had to take precedence.<p>I am not surprised to see the Netflix consumer API shut down. This will, of course, result in rampant screen scraping and the creation of an unofficial Netflix API, which, when it breaks, will be all Netflix's fault.
Netflix just keeps creeping one tiny step at a time farther and farther away from the awesomeness that they once were.<p>I used to love Netflix. I was a loving, loyal, evangelical customer and fan.<p>Now I just find them somewhat useful. In the future, who knows?
Netflix is big enough not to need a public API, so they are closing it.<p>It also makes things a bit easier on the technical side after they moved away from generic "REST" to device optimized APIs.
Good. Drive them into the ground, Jeff.<p>What was it, 2003-04 when Blockbuster's engineering team sent Netflix that concession letter? 10 years go by and guess who's stuffing their bra for lack of content.
Does anyone here happen to know how Netflix is charged for content? Specifically, do they pay owners per viewing while they have a title licensed, or do they license get a license for unlimited customer uses? And, even if they do get rights for serving an unlimited number of viewings, do they have to supply the usage data to the content owners, who may use the information in future negotiations.<p>I ask, because it seems like these details would have pretty significant impact on Netflix's incentives for effective recommender systems and user portals. They would need to balance the satisfaction rates necessary for retention of subscribed customers with variable costs of serving content, especially recently released feature films.
Seems like you could just watch the network for whatever those apps are doing and reverse engineer whatever remains of the API. You might not be able to build a business on that, but you can build your own apps for yourself, friends and your family that way.
I think the list of 3rd party services they are <i>not</i> going to shut down shows a weakness -- without an easy public API to use, it is less likely other such services that extend and add value to the Netflix experience will evolve.
8 projects made that they are now incorporating into the product proper.<p>These 8 projects were at cost of management of the public API.<p>If true that more projects of equal caliber will be developed in the future, what is the opportunity cost of maintaining the API? How would you measure this opportunity cost?<p>Corollary: If Netflix had gone Tesla with the public API, I'm talking a full developer tool marketplace platform- what would be the opportunity risk/reward conversation look like? I'm thinking would be a very valid strategy for cornering the video media marketplace, setting the groundwork to take a bite out of YouTube/Twitch/etc's marketshare.
This is the problem with modern web companies:<p>Protocols, not companies. There should be a Netflix protocol that any business could host. There should be a Twitter protocol so anyone could set up a Twitter server.
Having a public API is about growing new services that can rely on your data.<p>Imagine if they had never had one, would flixter, etc have popped up?<p>A public API can save you money in the long run by offsetting the risk/reward of trying new things with the data and diversifying.
Does this mean Android apps, like NetQ[1] are essentially done?<p>[1] <a href="https://play.google.com/store/apps/details?id=com.sporadicsoftware.NetQ" rel="nofollow">https://play.google.com/store/apps/details?id=com.sporadicso...</a>
Well they're still recruiting for their API team but I guess it is an internal API now: <a href="http://jobs.netflix.com/jobs.php?id=NFX01289" rel="nofollow">http://jobs.netflix.com/jobs.php?id=NFX01289</a>
Bateflix[1] is noticeably absent from the list of partnered apps.<p>[1]: <a href="http://bateflix.com/" rel="nofollow">http://bateflix.com/</a>
I don't know what is the big deal. It's as if these startups were in a Bachelor/Bachelorette style of competition and everybody but a few lost. It's not like the terms and conditions said the API would be there forever or for everybody.