Request Throttling Limits

Question

What are permissible requests "speeds?"

The API will cut you off if you make more than 30 requests over 5 seconds to any single endpoint (currently 30 requests per second, https://api.stackexchange.com/docs/throttle).

We consider this a breach of the API interface contract, so you won't get a nice error back. The exact manner in which this constraint is enforced can (and will, in all likelihood) vary over time. Attempts to work around this limit will be consider unconscientious use of the API.

Note that you can stay within this limit and still blow through an entire [app]s quota in less than 1/2 an hour.

Answer 1

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.RequestQueue.setInterval(170);    

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

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.

---

"30 requests over 5 seconds" leaves a lot to the imagination.

Does that mean that I can maintain a sustained rate of 6 request per second for a reliable rate of 360 per minute without error which would equal 10800 over a period of 30 minutes?

Is there no burst allowance and if there is, what is the cooldown?

If you could give clear guidelines that everyone can follow without the need to interpret something that can, well, be interpreted in many ways depending on how much experience or knowledge of throttles one may have.

We must construct our client libraries to respect the throttle while providing a nominal request rate and these numbers are crucial to that end, otherwise the apps that are built on them will be brittle.

And when you say 'The exact manner in which this constraint is enforced can (and will, in all likelihood) vary over time.' do you mean that the throttle numbers are going to remain constant but response to a throttle violation will change, or the other way around e.g. are we going to deploy apps and package and distrbute libraries that make every effort to respect the states limits only to have them change without notice?

Please be more specific so as to remove ambiguity and so that we may be more compliant without confusion, guesswork or complaints.

This is a truly critical issue and whatever the final decision/numbers are is fine as long as they are clearly defined.

Sincerely, Sky Sanders

Answer 2

I am not sure if it has fallen off the radar or if it is an honest oversight but we can't seem to get an explicit description of the throttling guidelines.

Core issues like this are critical, especially for library developers, and care should be taken to be as explicit as necessary to clearly define the guidelines.

Case in point:

My lazy loading library uses a gateway that is cached and throttled.

If the throttle limits are calculated globally, I will return a common gateway from the gateway factory that all requests are routed through, resulting in a max of 6 requests per second from my IP to your IP.

if the throttle limits are calculate per endpoint, I will return a distinct gateway for each endpoint, resulting in a max of N * 6 requests per second from my IP to your IP.

This is why it is important to be as explicit and detailed as necessary in order for a reasonable person to be clear on the guidelines.

casual documentation of core issues that can result in systemic failure of libraries and/or banning of IP/Keys is not responsible stewardship.

And if there are those that think I am just being contentious, let me assure you that I and several other professionals are very wary of building anything on top of this API due to the lack of professional response to mission critical issues such as this.