I have confirmed that a constant interval of 170 ms will run without error.

// 30 per 5 sec = 6 per sec =    interval 166.6 ms

Soapi.RouteFactory("api.meta.stackoverflow.com", apiKey)
   .Tags({ pagesize: 1 })

will run through all the tags on meta 1 at a time without issue.

This is very much a fix to an elusive problem.

Thanks much and if there is any more clarification you can provide regarding burst allowance and/or the complete lack of burst allowance that would also be appreciated.

see https://stackapps.com/questions/1143/request-throttling-limits


I am currently running different permutations of tests to find a sustainable burst rate and hopefully suss out a max per minute figure for each endpoint.

Current results

  • 250 ms stream runs to 1200 test stopped with no errors seems to indicate 240 per minute limit - burst allowance not determined
  • 200 ms stream fails @ 990
  • 30 burst 7 seconds cooldown runs to 1300 test stopped with no errors
  • 30 burst 6 seconds cooldown fails @ 780
  • 100 burst 20 seconds cooldown fails @500

It sure would be easier to comply with a throttle and write code, especially code that is user initiated on a central server, to avoid violating a throttle if some numbers were provided by someone.

My observations (1, 2) that the nature of api requests are different than those generated by SE sites and should be handled differently, e.g. as api.stackoverflow does, have fallen on unsympathetic ears.

e.g. it takes 10 seconds to retrieve 30 records from api.stackauth.com/1.0/users/{id}/associated if you wish to avoid 503 errors in html format.

It seems to me that if there is to be a throttle limit after which the JSON interface breaks down and 503 errors are thrown in html format, we need to be aware of this interval/threshold in order to avoid this limit and provide capable client libraries/applications with clearly defined behavior.

In my working copy of Soapi.js, I have implemented a throttled request queue and setting the throttle to 3 request per second (painfully slow for an automated process!) for endpoints other than api.stackoverflow.com and this seems to satisfy the throttle for a short time. After a few hundred requests at this rate, 503 errors again begin to be thrown.

I believe I have found some documentation on the module being used to throttle api requests on all api endpoints except api.stackoverflow.com.


Whether or not this is the module being used to throttle the requests, a clear and explicit specification of the throttle numbers would be of great help in avoiding the tripping of the throttle and providing capable applications/client libraries with clearly defined behavior.

It would also be very helpful if the 503, for api requests, was returned as JSON and, for JSONP requests, with a status of 200.


api.stackoverflow.com does not seem to apply a throttle, other than the 10,000 request rate-limit, to api requests. This seems to me to be the appropriate behavior when dealing with API requests. This is also what leads me to believe that the application of the throttle on the other sites is an oversight.

  • 1
    Haha (@your most recent edit)
    – jjnguy
    Jul 13, 2010 at 16:36

2 Answers 2


Request Throttling Limits


If you are not using an API key, you are limited to 300 requests per day per IP address

  • 2
    you are referring to rate-limit which a different issue. Jul 16, 2010 at 3:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .