Five Notable Changes in Twitter’s New API

Many developments happened last year on Twitter. News of the iPhone 5 being jailbroken, Nokia mocking HTC over the latter's WP8 devices, renowned mobile OS security expert Charlie Miller joining Twitter and of course, closer home, Sam Pitroda's virtual press conference. All this, even as Twitter announced plans for its new API, criticism followed and the changes were defended by Twitter while trying to assure developers of interactivity in their apps. Let's take a closer look at some of those changes.

SNAPSHOT

Applies to: Web developers

USP: Ensure that your Twitter clients continue to work properly with the new API

Primary link: http://ld2.in/4h8

Search Engine Keywords: Twitter API, Twitter, Tweet, Twitter client

1. Authentication

Version 1.0 of the Twitter API allows developers to access certain API endpoints without requiring their applications to authenticate. This however results in essentially public access to a large amount of information with Twitter knowing little about the application (and more specifically, the user) making the request, beyond the IP address. Hence, in version 1.1, Twitter requires every request to the API to be authenticated. For developers who are already using OAuth when making API requests, all of your authentication tokens will transition seamlessly from v1.0 to v1.1. If your application is currently using the Twitter API without using OAuth, you will need to update your application as soon as possible since as of the time of writing, March 5 is the date when the older API will be deprecated.

2. Per-endpoint rate limiting

V1.0 limits the number of authenticated requests applications can make to 350 calls per hour, regardless of the type of information the application was requesting. In V1.1, Twitter provides per-endpoint rate limiting on the API. While an application that only accesses one endpoint may be more restricted, applications that use multiple endpoints will run into rate limiting issues less frequently.

Most individual API endpoints will be rate limited at 60 calls per hour per-endpoint. There are a set of high-volume endpoints related to Tweet display, profile display, user lookup and user search where applications will be able to make up to 720 calls per hour per endpoint.

3. Display Requirements

To ensure that Twitter users have a consistent experience wherever they see and interact with tweets, in V1.1 of the Twitter API, Twitter shifts from providing Display Guidelines to Display Requirements, including those for mobile clients. Twitter requires all applications that display Tweets to adhere to these. Among them are: linking @usernames to the appropriate Twitter profile, displaying appropriate Tweet actions (e.g. Retweet, reply and favorite) and scaling display of Tweets appropriately based on the device. If your application displays Tweets to users, and it doesn't adhere to the Display Requirements, Twitter reserves the right to revoke your application key.

4. Certification Requirements

With V1.1, pre-installed client applications need to be certified by Twitter. Once again, if you ship an application pre-installed without it being certified by Twitter, Twitter reserves the right to revoke your application key.

5. Large Token Requirements

Twitter now requires you to work with them directly if you believe your application will need more than one million individual user tokens. 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 their User Streams product, you will need their permission if your application will require more than 100,000 individual user tokens.

Twitter will not shut down client applications that use those endpoints and are currently over those token limits. If your application already has more than 100,000 individual user tokens, you'll be able to maintain and add new users to your application till some time depending on your current number of user tokens. Once the limit is reached, you'll be able to maintain your application to serve your users, but you will not be able to add additional users without Twitter's permission.

Looking ahead

Thus, for developers who are already making authenticated calls to the API in V1.0, the migration to V1.1 will be relatively easy, and should only involve updating the API endpoint, and testing your application's behavior against the new rate limiting policies. Beyond API v1.1 too there are some changes planned, such as moving to 64-bit Twitter user IDs later this year.

If you have developed a Twitter client, have you migrated it to comply with API version 1.1's requirements? Let us know your experience and concerns by writing to us at pcquest@cybermedia.co.in