Hi Developers,

A few quick points before I go into more detail:

  * For the Search API, you should *only* be using
http://search.twitter.comto execute search requests.
*Not* http://api.twitter.com/1/search or any other variation.

  * *Next week*, we plan to remove the erroneous, unsupported endpoint at

  * All REST requests to the API should use the fully qualified hostname and
API version in URLs: http://api.twitter.com/1/* -- no other version is valid
at this time.

  * All OAuth negotiation steps should be over SSL and also at
http://api.twitter.com -- but without a version.

  * Don't execute the same search query more often than every 20s and always
use since_id on subsequent requests

  * Consider the streaming API if you're relying on search heavily to power
your application

*The Long-winded Approach*
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.

For those using http://twitter.com/search, http://api.twitter.com/search, or
http://api.twitter.com/1/search -- you've been doing it wrong :)

Though we should have rejected traffic to that end point long ago to avoid
confusion, it was never intended as a valid resource for search queries.

Next week, we'll be properly closing off this end point to avoid further
confusion. If you have code today that uses the http://api.twitter.com or
http:/twitter.com domains to execute search requests, be sure and update
your code for the proper end point.

You can find the Search API documentation at

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

While we're on the topic of using the proper endpoints, a general reminder
about endpoints with the Twitter API:

All REST resource requests, with the exception of Search, should be pointed
at http://api.twitter.com/1/* -- always use the api subdomain and specify
the version number ("1"). No other version number will be accepted for the
API at this time and your requests will fail if you provide a different
string or integer.

All OAuth negotiation steps should be over SSL at
https://api.twitter.com/oauth/* ("
https://api.twitter.com/oauth/request_token";, "
https://api.twitter.com/oauth/authorize";, "
https://api.twitter.com/oauth/access_token";, "

Let us know if you have any concerns about the removal of the
unofficial/unsupported search end point. We don't want to break people, but
we also don't want you using unofficial API calls with substandard and
unpredictable responses.


Taylor Singletary
Developer Advocate, Twitter

Reply via email to