Every response from the API can be cached for up to a minute, so making the same request multiple times in that time-frame typically won't return different results.
We make note of this in the throttle documentation:
While not strictly a throttle, the Stack Exchange employs heavy
caching and as such no application should make semantically identical
See How API Keys Work. It's six years old, but a leading API developer said:
... If you can demonstrate a need for a higher request quota, contact us.
However, the Key limit should be sufficient for development, so please only request an increased quota when your application is live and has a non-trivial number of users.
(Emphasis and contact link ...
You can get data close-enough to "real time" for most practical purposes. See the StackHose app, for example.
Read the page about the API's Throttles and Quotas. From that page we can deduce:
The maximum, burst, request rate is 30 requests per second, and this risks getting your app shut down.
Your app will never be allowed more than 10,000 requests per ...
backoff isn't used to indicate when you're breaking api limits (we start returning errors when you break contracts).
The typical cause of a backoff is a request that takes unusual resources to run. These are normally either complicated queries or high page values; however, backoff is applied dynamically so the exact definition of "complicated" and "high" ...
You might consider looking at StacMan for inspiration, a C# client that deals with some of these questions.
Off hand it does push everything through a "Manager" (called a Client in that code) and automatically enforces backoff and simultaneous request throttling.
How many requests are OK to send simultaneously?
While there is a strict cutoff... ...
This file is provided to API clients to automate various tasks, initially focused on login.
In fact the SDK really only does one thing. It helps you get an access_token if you need to authenticate. It ...
The documentation for the response wrapper defines the backoff field as an integer, so you can expect it to come back in the first form.
I don't believe there's any way to graciously test a backoff response short of actually angering the API (which I'd recommend against).
Your app is subject to IP throttling as explained in the rate limiting documentation:
Every application is subject to an IP based concurrent request throttle. If a single IP is making more than 30 requests a second, new requests will be dropped. The exact ban period is subject to change, but will be on the order of 30 seconds to a few minutes typically. ...
It sounds like you've either got a bug which is in fact making more requests than you think it is, or you're on a network where there's some other source of high-frequency requests.
You're not supposed to have to deal with this situation in general, because this isn't an API error - it's an error from the load balancer because your IP is generating incoming ...
The comments are more or less correct; caching applies to the /events endpoint just like every other method.
This is by design for now. We have looked at differing caching policies for /events and /inbox/* routes, as the minute lag on those methods is a bit heavy handed; though we still need to protect ourselves from abusive requests.
The page where you can find the API key for your registered application says that the key doesn't need to be kept secret:
[The key] is not considered a secret, and may be safely embed [sic] in client side code or distributed binaries.
Abuse is typically an issue for the end-user, so you shouldn't be concerned about it beyond recognizing backoff responses ...
Provided you don't do anything "evil" (which basically means leaking user messages to people/apps they haven't authorized), we have no objections to a generic push service.
Yes, the per-minute throttle is for the same request; changing the parameters counts as separate requests. Do note that the 30 requests/second cutoff is by IP (it's a DOS prevention ...
From my personal observation and from the occasional SE dev statement, many items update every 60 seconds (cached at server).
Also the page AJAX updates every 60 seconds.
(using JS like: setInterval(updateRelativeDates, 60000);)
So, per sampling theory, sampling more than once every 30 seconds gives diminishing returns.
Personally, I would just reload ...
Your app can just give them the link, and they don't need to be logged in.
The quota is a function of your API key (mainly).
Register your app and use a key and that will give you a 10K quota.
How API Keys Work.
Looking for a beginner's tutorial to using the API.
How to make a Stack Exchange API call, using my key
Yes, it is perfectly okay. You only need an access_token (OAuth/login) if you are trying to change data, or are accessing private information for a logged-in user.
See the Authentication docs for more info.
The issue you are having with has_more is unrelated and is a known, current, bug.
Aside: Using an access_token will never decrease any secondary ...
You can do this on the API with far less than 120K requests. Just use a different approach.
Instead of getting a total for every single month, offload that work to your app. Use a /search query to get the questions for the whole interval in question. EG:
That error means that you have used up your API quota for the day.
You are allowed either 300 or 10,000 API requests per day for each IP address, or app, depending on whether you use an application key and/or an access_token.
The "Throttles" documentation
What are the API request limits? (FAQ)
Request Throttling Limits (FAQ)
Note that you must ...
Or can I just spam them out as fast as my program can send them, as, like you said, you cache it anyway.
No. The throttle discussion page specifically says:
... we consider > 30 request/sec per IP to be very abusive and thus cut the requests off very harshly.
And even though the underlying data is cached for 60 seconds, the HTML requests are not. You'...
See the Throttles doc page.
The 10K limit is not if the customer registers, it is if you register your app and provide the key when you make API calls.
Also, you can get more than 10K per IP if your app authenticates the user and then passes a valid access_token. In that case, it becomes 10K per logged in user and does not share the 10K IP limit.