Twitter ditches whitelisting, tells developers to deal with it

Twitter’s Ryan Sarver (@rsarver) sent out an email a couple of days ago to the Twitter API Announcement list stating that they will no longer grant whitelisting requests for the REST API, meaning developers who aren’t already whitelisted will have to deal with 350 GET requests per user per hour no matter what.

This in itself is reasonable. Whitelisting comes from a time where everyone, no matter what, was restricted to just 150 API requests an hour and there were less flexible API requests available (and no streaming API). What I find interesting is this quote:

We also want to acknowledge that there are going to be some things that developers want to do that just aren’t supported by the platform. Rather than granting additional privileges to accommodate those requests, we encourage developers to focus on what’s possible within the rich variety of integration options already provided.

It sounds innocent, and I don’t think Ryan is meaning it in in a sneaky way, but in my mind it highlights Twitter’s change in attitude about the third-party ecosystem surrounding the service. No longer is it all about the developers (though they still support developers a great deal, I’m not denying that), because they have the capacity to bring people inside Twitter and have them develop for them instead, providing them with whatever private APIs they need (Tweetie is the biggest example of this). It used to be about giving developer’s features first to see what they come up with, now they’d rather add the feature themselves and add it to the API “soon”. For example:

  • Twitter for Mac can shorten URLs using t.co, a feature I would love to use on Twitterfall to ditch URL shorteners to improve user security (blog post coming soon about this).
  • Twitter.com can show you replies to a tweet, a private API that I once tried to emulate, but couldn’t due to scaling issues.
  • When Twitter shut off basic authentication, they gave their Android app a backdoor in because it wasn’t ready.

The first two would be great in third-party clients, but Twitter haven’t released them. Maybe that’s due to scaling issues, but surely Twitter for Mac and Twitter.com are both orders of magnitude more popular than third party clients nowadays? And everyone seems to run a URL shortener these days. If they’re so committed to security, why not let third-parties use it?

I know the Twitter API is a free service and we’re lucky to even have it, but third-party developers were what helped make Twitter as successful as it is today, and as I’ve shown above it’s not just about features, it’s about security too. I would like to see a faster turnaround of private APIs to public ones to show Twitter still want to support their ecosystem.

Dave Winer comments on how Microsoft did a similar thing back in the day (and now?).

This entry was posted in Blog. Bookmark the permalink.
  • Rio

    I actually think That third-party useage of Twitter is higher than most web-apps simply brcause of the paucity of features and the need for more efficient data displays. I’m not sure how I regard the REST limits- quite frankly you cant do much that is useful with 350 requests. I hope they don’t cap the Firehose, for TwitterDot’s sake!

    • http://jalada.co.uk Jalada

      350 is alright when it’s per user. If you poll for timeline, mentions, and DMs you can poll every 30 seconds! Way more than needed.

  • Pingback: Twitter: Let us use t.co so we can get rid of short URLs | Jalada

  • Pingback: Quora