Twitter to Remove "Unofficial" Search Endpoint Next Week

Adam DuVander
May. 28 2010, 12:23PM EDT

If you're using Twitter's Search API via the api.twitter.com sub-domain, you have a week to switch to search.twitter.com, according to a post from Twitter's Taylor Singletary. The endpoint being removed has not been officially supported by Twitter, though other supported calls use the same sub-domain.

Singletary writes:

The only endpoint you should be using for search operations in the Twitter
API today is http://search.twitter.com -- it doesn't require user
authentication or OAuth -- simply identify yourself with a user-agent that
is unique to your application.

It's important to note that Twitter is not taking away any functionality from its API. It is merely making clear what could be potentially confusing to developers. Twitter's main API for authenticated commands, such as fetching timeline data and creating new tweets, will continue to be operational on api.twitter.com. The change only affects developers using the search API from the unsupported sub-domain. The confusion could have come when Twitter moved to a versioned API, because the search API is not versioned.

Singletary also had some good developer tips for making the best use of the Search API:

Many users of the Search API are better served by using the Streaming API.
If you use the search API to track the tweets of specific users, hashtags,
or simple keyword queries, it is highly recommended that you use the
Streaming API instead.

You shouldn't issue the same request to the search API more frequently than
once every 20 seconds -- if you issue the same query more frequently than
that, you're in danger of getting blacklisted. In addition, if you find
yourself repeating the same query frequently, be sure and make use of the
since_id parameter on subsequent requests -- without it, you put undue
stress on the search infrastructure and will also be in danger of
blacklisting.

The Search API is bound to put significant stress on Twitter's servers. That's likely the biggest reason for having search on its own sub-domain. Engineers are able to have search servers tuned to its specific needs, without needing to support the authenticated calls.

Adam DuVander Hi! I'm Developer Communications Director for SendGrid and former Executive Editor of ProgrammableWeb. I currently serve as a Contributing Editor. If you have API news, or are interested in writing for ProgrammableWeb, please contact editor@programmableweb.com Though I'm a fan of anything API-related, my particular interest is in mapping. I've published a how-to book, Map Scripting 101, to get anyone started making maps on websites. In a not-so-distant past life I wrote for Wired and Webmonkey.

Comments