For the first use case, following many users' timelines, you should be using the follow method on the Streaming API. Currently you cannot get protected and low quality user statuses this way, but you can get the vast majority of tweets this way. Until we support these corner cases, you can fall back to the REST API for protected users.
For automated hashtag searching, you should also be using the Streaming API. The track feature will give you all hashtags search for up to a fairly generous proportion of the total stream of tweets. -John Kalucki http://twitter.com/jkalucki Services, Twitter Inc. On Fri, Jan 1, 2010 at 2:43 PM, jojet <j...@jojet.com> wrote: > Hi all, > I was feeling a little clever after working on some Twitter API stuff > but then thought "oh! I'd better think about Twitters rate > limiting"...and then that's where my brain started to melt! > > A few bits of info: my web app needs people to authenticate (OAUTH) > and, from then on, the app analyses their tweets and occasionally > updates registered user's statuses. > > I've applied for the webserver IP to be white listed which I believe > gives the app 20,000 requests per hour. > > I've not found the search API to be great when looking for a hashtag > (sometimes tweets just don't seem to get indexed) so I've gone a stage > further and am analysing the individual timelines of all my registered > users via a cron job (the cron job sucks in all of a persons tweets > greater than the last analysed tweet of the user). This call is made > via OAUTH/authenticated so I believe such a call depletes the user's > rate limit quota rather than the IP/authenticated account of the > webserver quota? Is that correct? > > Thanks for any thoughts here > > Joel > > > > > > >
