The information in @BrockAdams explanation is useful, but needs some clarification:
Quota Pool
As mentioned in the API Throttles Doc, all calls with an access_token
work from a shared quota per IP. Using multiple API key
s will not increase or change the quota. Only calls made with a user-based (logged-in) access_token
create distinct pools.
More detailed information can be found in the doc on Throttles linked above. While I have tested and confirmed that different access_token
s have distinct pools (and that different app key
s do not), I have not tested multiple-IP scenarios personally.
Reset time
For any given quota pool, the next reset will occur 24 hours after you made your first API call following the previous reset.
That algorithm can honestly be a bit difficult to parse in English, so some examples can be useful. All times below can be considered either "local" or UTC -- It doesn't matter:
2023-12-05 at 08:00: You start using the API and make your first call at 08:00 local time. With an API
key
in your calls, you have a default 10,000 quota for the next 24-hours.You exhaust your quota within 24 hours (exactly when does not matter).
2023-12-06 at 07:59: The next day, you attempt to make an API call, and it will fail because the quota will not reset until 08:00.
2023-12-06 at 08:00: The quota resets.
2023-12-06 at 09:00: You make your next API call, which will succeed (based on quota). This is now the first API call following the previous reset. It will be another 24 hours until the next reset.
You again exhaust your quota within 24 hours (exactly when does not matter).
2023-12-07 at 08:30: You attempt an API call, which will fail, because the next reset won't be until 09:00.
Real-world Implications
Honestly, most usage is never going to need 10k calls in a 24 hour period. A more likely scenario is that you may just be making your calls without a key
at all. That's completely natural when starting off with low-usage of the API. In that case, you'll be getting the default 200 and be more aware of the decreasing quota. Of course, you can always start using a key
to get around that if needed.
Regardless of your quota size, if you need it, the biggest problem with the current implementation is that you won't know exactly when your reset is unless you keep track of that first call of the 24-hour period.