I've "discovered" that the API rate limit is 450 per hour for pages/ cursors within a "followers_ids" or "friends_ids" call, if that helps. But I really think that increasing the API rate limit for basic HTML auth is a bad idea - let's make oAuth work!
On Jan 20, 3:04 pm, Josh Roesslein <jroessl...@gmail.com> wrote: > Yeah an increase in API requests would be nice to have with the > addition of new API features. > I would almost like a solution where twitter sets a "guaranteed" > hits/hour soft limit. > By soft limit I mean if you go above this limit you "may" be rate > limited if the twitter cluster > is currently under heavy load or you are being too rough with the API. > If the cluster has unused capacity, > why start limiting users? For non-whitelisted applications a guarantee > of 250 would be nice. Whiltelisted apps > would get a higher guaranteed limit still to meet their demands. > > I'm sure twitter has floated this idea around. Not sure how big of a > technical hurdle it would be to implement. > Just my two cents on the subject of API rate limits. > > Josh > > On Wed, Jan 20, 2010 at 4:48 PM, Eric Woodward <e...@nambu.com> wrote: > > I will come straight to the point: we need to an increase to the API > > limit to properly implement Twitter within a desktop client > > application given the addition of: 1) three retweets timelines; 2) > > checking the account's saved searches; and 3) up to 10-20 Twitter > > Lists timelines. > > > Twitter Lists alone are causing real problems if a user follows more > > than 5 or so. We cant poll Twitter List subscriptions with one API > > call that combines them altogether, which we could then split apart > > client-side with some attached meta-data. That alone would have been a > > big help, and without it we are left polling each List as if it was a > > separate timeline, since that is what they are. > > > Implementing proper Lists management is a non-starter within this > > limit, so is regular confirmation of a relationship between two users > > when asked for by the user (on Lists or search results). There is > > simply a lot of stuff I cannot do properly that is standard on > > twitter.com, all because I am subject to the API limit while > > twitter.com is not. Users simply do not understand this distinction in > > possibilities. > > > I would like to formally ask on behalf of all client developers that > > the API limit increase to 250, from 150, for all applications whether > > they use OAuth or HTTP Basic Authentication. We are simply not able to > > implement Twitter properly within a limit of 150, but dont need a lot > > more, only another 100-200 API calls or so. > > > If Twitter can even technically contemplate a 10x API limit increase > > to 1,500 for OAuth applications, surely an increase to 250 based on > > the addition of core features like official retweets and Lists is a > > reasonable request. A limit of 150 is simply obsolete, and has been > > for a long time. > > > I do not want to wait for the UX repairs around OAuth for desktop > > applications, and I dont like being forced into OAuth sooner than we > > are ready just because we need the extra API hits just to do basic > > features properly. And besides, that was announced as two weeks away > > three weeks ago. I dont want to wait any longer. I want to properly > > implement the basics, like Lists polling, now. > > > This is a considered email because I care about the quality of our > > Twitter implementation and I care about the Twitter ecosystem. I would > > appreciate a considered reply. > > > --ejw > > > Eric Woodward > > Email: e...@nambu.com
