Twitter API v1.1 Good and Bad parts

So the Twitter API version 1.1 is finally released ! Trust me I've been checking the Twitter API docs and blog almost everyday after the API change announcement last month. I'm sure many others did that too. As you might already know the developer community is not quite happy with the announced changes. However, with the bad parts there're some good parts attached too. Let start with the good parts:

{ Twitter API v1.1 The GOOD Parts }

: Increased per-endpoint rate limits for 6 methods :

• GET search/tweets
• GET statuses/oembed
• GET statuses/show/:id
• GET users/lookup
• GET users/search
• GET users/show

The limit is increased to 180 calls per 15 minutes from the previous 350 (authenticated) & 150 (per-IP) limit. Which sounds great ! That means we now get 720 calls per hour for each of those methods mentioned above, however, not exceeding 180 calls per 15 mins. So, we should not hit rate-limit with 1 call per 5 secs:


720 calls per 60 mins == 3600/5 = 720
180 calls per 15 mins == 900/5 = 180
12 calls per 1 min  == 60/5 = 12  
1 call per 5 secs


For many application 1 call per 5 secs won't be practical  but for many others it is. Anyways, the new API only limits the calls to 15 mins window. Technically, that's means you can consume 180 calls limit in 1 min if you want. (I've not tested yet though)

 Just to remind, these limits are per token (or for each user of your application) and per method/endpoint (each of the 6 methods) as Twitter API v1.1 still uses the OAuth 1.0A authentication model as quoted below:

Application-user authentication: [ a.k.a Requires user context ]

This is the most common form of resource authentication in Twitter's OAuth 1.0A implementation to date. Your signed request both identifies your application's identity in addition to the identity accompanying granted permissions of the end-user you're making API calls on behalf of, represented by the user's access token.

In case you're wondering, the new "Require User Authentication" in the Authentication field of the API docs is explained here:

Most integrations with the API will require you to identify your application to Twitter by way of an API key. On the Twitter platform, the term "API key" usually refers to what's called an OAuth consumer key. This string identifies your application when making requests to the API. In OAuth 1.0a, your "API keys" might refer to the combination of this consumer key and the "consumer secret," a string that used to securely "sign" your requests to Twitter. Most requests to Twitter require a user context in addition to the application context. User context is presented through the use of another kind of token/key called the "access token." See Obtaining access tokens for more information.

Further, in API v1.1, the response format of the Search API has been improved to return Tweet objects more similar to the objects you'll find across the REST API and platform. Which is cool !

: Twitter Client Policy Change :

This one pissed-off many app developers. In the earlier announcement this change was not clear : 

The 100,000 user token limit applies only to the small number of clients replicating the core Twitter experience - it does not apply to the majority of other applications in the broader ecosystem.

Whereas the earlier announcement said:

Additionally, if you are building a Twitter client application that is accessing the home timeline, account settings or direct messages API endpoints (typically used by traditional client applications) or are using our User Streams product, you will need our permission if your application will require more than 100,000 individual user tokens.

 It might be debatable that it still says the same thing with different words but it is what it is  :)

{ Twitter API v1.1 The BAD Parts }

: 15 calls per 15 minutes for all other methods/endpoints :

Again , if you think from the authenticated calls perspective, it was worse earlier - 350 calls per hour total for all of the available methods. Now, we have 60 calls per hour for each of these methods (excluding the 6 of-course)

: Display-guidelines  == display-requirements :

I think many applications follow the display guidelines already. Those who don't now have to follow. Is it a bad news ? Well, may be for some. Solely depends on the App UI design. Some already existing apps might  have to do a bit of work and modify the UI design to be compliant with the Twitter display requirements. Some points in the requirements that developers might not like are:

• Hashtags must link to a twitter.com search with the hashtag as the query.
• Links in Tweet text must be displayed using the display_url field in the URL entities API response, and link to the original t.co url field.
• No other social or 3rd party actions similar to Follow, Reply, Retweet and Favorite may be attached to a Tweet.  // This one made a bit of noise in the community, you know why !

: No RSS feeds, Only JSON  :

This one might hurt couple of applications. Although, JSON is better than RSS/ATOM the web/blogosphere is still on RSS and convincing the entire web to move to JSON (or similar) is going to take time. Many consumer and apps rely on RSS for content consumption. I loved the  RSS feature too, it should not have gone away :(

: No per-IP or unauthenticated calls : 

Well, about this one I'm a bit sad too as it'll kill most of the client-side only (JavaScript based) apps which worked without authentication. I'm a JavaScript  and client-side only apps lover. Still, I think this change does not imply that Twitter hates developers or client-side apps but because of there're a lot of morons (in compare to good developers ) out there who continuously hit Twitter's server hard without any mercy just for profit. Just because the quantity of these morons are more than genuine app developers, this change was expected . I guess Twitter made it clear in the last announcement anyways:

There are many applications that are pulling data from the Twitter API at very high rates (scraping, bots, etc.) where we only know the IP address of the applications. To prevent malicious use of the Twitter API and gain an understanding of what types of applications are accessing the API in order to evolve it to meet the needs of developers, it's important to have visibility into the activity on the Twitter API and the applications using the platform.

But the real bad part is finally the good developers pay the price for the deeds of the morons. As we've witnessed many times before the bad guys find their way out. Scraping is still possible, hitting Twitter's servers hard is still possible. It is not a solution to end the problem but it might help Twitter a bit. To be honest if any of us were running Twitter we might have ended up taking similar decisions if not exactly the same. Think about it. It's really hard to run a company and give away APIs for free which is struggling hard to find a stable and profitable revenue model.

I am no expert to comment but these BAD parts are actually to keep Twitter alive, which all of us want for sure. I still like Twitter and will use their APIs to build apps,  even after all those bad press and the unexpected API changes. At-least, they're still giving back to the community for free!

Twitter has got their own problems to solve and so do we. It is for sure that the changes will kill many apps, including the good and genuine ones and for some apps these changes don't matter much. But again , rather than dwelling on what's gone, let's focus on what's there and solve the bigger problems..bugs in our elegant code..ohh..where's my sublime-text2 :)