Netflix API Developer Blog

Having trouble getting one of the steps in the OAuth Dance exactly right? The Netflix Authentication Walk-Through is here to help. Through the magic of copy-and-paste, the Walk-Through will guide you from your first token request all the way through to adding, changing, and deleting live user queue items. There's nothing to install on your end; everything works from your browser, with nothing to install or manage.

The Walk-Through is also useful for testing. You'll be able to use your own application's callback, if you like. You'll be able to view your signed URLs all the way through the process, which is especially handy if you're having trouble understanding (or rolling your own) OAuth library.

One of the developers made a reasonable observation that the app gallery should accept portrait-oriented screenshots given the number of mobile Netflix apps out there.  This is now supported.  The same dimension restrictions are enforced, but the image can now be either in landscape or portrait orientation.

As the OAuth community and other news outlets are reporting, a security exposure has been identified with the OAuth protocol’s application authorization process we use to allow third-party applications to access the Netflix service on a subscriber’s behalf. 

The Netflix website and our partner movie players (listed here) do not utilize OAuth and are therefore unaffected by this vulnerability.  Netflix javascript widgets on sites like The New York Times and Rotten Tomatoes are also unaffected.

After examining the threat in the context of the API capabilities we provide, we’ve determined that the risk is not substantial enough to suspend our OAuth support at this time.

We have taken steps to minimize the risk to our subscribers by minimizing the validity period of OAuth request tokens which makes the attack more difficult to orchestrate.  We have also added a warning to our OAuth application authorization page to warn subscribers about the potential risk and help them identify if they are taking part in a compromised authentication session.  In the coming days, we’ll continue to work with Mashery and the OAuth community to resolve the exposure.

More information on this issue is available at the OAuth website.  We will notify the developer community via this blog if our policy on this issue changes as well as any modifications to our OAuth support.

The soon-to-be-released Netflix App Gallery is now open for developer submissions!  You can create your entry for the gallery by going to the "My Account" page on the developer portal and then selecting the "My App Gallery Entry" link.

A couple items to note:

1. We'll launch the Gallery to Netflix members when we feel we have a minimum list of applications.  We don't expect this to take that long given the number of apps out there.
2. While the Entry details page says that the application description is limited to "100 chars or less", we'll support longer descriptions of up to 600 characters on the application detail page and show the first 200 characters of that description when your application will be shown in list views.  Note that you can supply a link from your app entry to a more complete application description, download link, etc.
3. Reminder: each submission will be reviewed for Terms of Use compliance before it is published to the Gallery.

We're looking forward to promoting your applications to Netflix subscribers!  Please comment on this post using the link below if you have any questions or comments around submissions.

We're very happy to announce that we're about to roll out an App Gallery to showcase all of the great applications you developers have built using the API.  The App Gallery will be on the main Netflix website, so this is going to be a terrific way to tell our subscribers about your application.

The Gallery will be rolled out in two phases.  In the first phase, we'll accept application submissions.  Once we have a decent initial set of applications will open up the Gallery on the Netflix website.

We're giving developers advanced notice of the launch so that you have extra time to address any Terms of Service compliance issues before we start accepting submissions.  We will be doing quick audits of all submitted applications, and the last thing we'll want to do is reject an application due to compliance issues. 

The most common compliance issues we've see to-date have to do with branding violations or improper OAuth implementation, whereby the application requests user name and passwords directly vs. handing the user off to our OAuth sign in page.  When in doubt, ask us for guidance in the forums.  Chances are, someone else has a similar question.

We'll do another blog posting as soon as the Gallery is open for submissions as well as send a tweet from the netflixapi Twitter account.

First off, huge thanks to David Westbrook, John Haren, Kirsten Jones, and Johnathon Wright. Why? Because these really smart people build libraries to call into the Netflix API. Thing is, they're not alone. There are other folks that have also built great libraries that do amazing things and generally keep you from having to read and implement that confusing section in our docs about how to handle request tokens.

Only we don't know who they are.

We'd love to, because I'd happily list them on the resources page and point folks at the well forged sweat of their respective brows in the forum, mail lists, twitter, and everywhere else I find folks looking for an easy answer. The only problem is, we can't do that unless you tell us about them.

(As a wise man once told me, "If you build something and nobody knows about it, why did you waste your time?")

So, please, let us be your cheerleaders. Tell us about your libraries so we can send you folks who need them, and thus ensure your fame, glory and accolades for generations to come. If your library isn't listed in the Showcase, (or you know of one that's not) please feel free to include it.

Want to see a .NET wrapper for the Netflix API?  All you have to do is provide feedback on the API under development by Jonathan Allen.  He does all of the work, you provide the feedback.  What a deal!

Go here for more details.

Earlier this week we rolled out some incremental API improvements and bug fixes.  Here are the highlights:

users/current resource

This resource returns a link to the currently authenticated user.  You can now access the active user's associated API resource without extracting the user ID from the OAuth access token response.  This should make use of OAuth libraries that don't support standard response extension easier to use. 

On a related note, we also are in the process of removing the need to pass the application name into the authorization (login) URL, which will remove the last of our (standard-compliant, but difficult) OAuth extensions that tend to trip up some OAuth libraries.

gzip support

gzip compression of API responses is now enabled for clients that pass the gzip accept header (see Conventions documentation for more details).  We typically see at least a 2x latency improvment in calls that use gzip- even more on larger responses and for clients on slower network connections.

lost request tokens

We addressed a couple bugs that lead to request tokens not getting passed in authorization service callbacks.

category scheme URL fix for catalog index

The category scheme URL for title formats in the index was incorrect and inconsistent with similar references in other resources.  We added the correct category reference to the catalog index.  The older, incorrect reference will be maintained until the next versioned update of the API, at which point the old, erroneous reference will be removed.

API URL 404s

We found a few cases where the API was returning responses for badly formatted URLs.  The API should always return a 404 if the URL supplied is not an exact match for the resource URL.  We don't want to be flexible in accepting near-miss URLs since they are also resource IDs, which there should be only one of for each resource.

The only flexibility we continued to allow short-term is the use of trailing slashes on resource names.  We will eventually disallow those as well, but we chose not to return 404s for resource URLs with this error until we do the first API release with a version change, in order to give developers time to migrate any old code that contains this URL error to the new API.

This is a good opportunity to remind everyone that you should be using API versioning to protect your code from any interface changes introduced in new versions of the API (see Conventions reference mentioned above for more information).  We avoid making interface changes whenever possible, but sometimes they are unavoidable.  API versioning is your friend.  Also note that we reserve the right too extend the interface at any time, e.g. new XML elements, API resources or URL params) without versioning the API.


I hope everyone enjoys these improvements.  Happy coding!

UPDATE: we've decided to postpone hack day until after the holidays in the new year.  Hope to see everyone then!

I'm excited to announce that in just three weekends we'll be having our first open Hack Day at the Netflix campus in Los Gatos.  The event will run from 12pm on Friday, November 14th through 3pm Saturday the 15th. 

Bring your ideas and mad programming skills.  Build one of the better hacks and walk away with the admiration of your peers as well as one of many prizes (Netflix-enabled Blu-ray player, anyone?)

Members of the API team will be on hand to meet you and answer any of your questions.  Food and ample supplies of caffeine will be provided, of course.

To sign up, please send your name, email address, and tentative project (if you know already) in an email with the subject "hack day" to apisupport@netflix.com.  We'll be accepting applications and selecting up to 100 participants on an ongoing basis through next Wednesday, Nov. 5th.

Please visit the hack day forum for more information, to get your questions about the event answered or to form teams.