Skip to main content
added 589 characters in body
Source Link

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 keys 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_tokens have distinct pools (and that different app keys 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.

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 keys 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_tokens have distinct pools (and that different app keys 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.

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 keys 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_tokens have distinct pools (and that different app keys 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.

Source Link

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 keys 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_tokens have distinct pools (and that different app keys 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.