According to How API Keys Work, the default daily API limit -- which is per site, per day -- is 300.

I started with 300, as expected, but over a period of days, I've noticed that the remaining quota has now been whittled down to about 70 something:

        { "user_id":0000,"display_name":"abc","account_id":00000 }

Even after the UTC reset today, the quota remaining is still the same. Is this a one time thing where when I use all of this up, that's it, I'm done for good, or is this a bug?

What's more, this doesn't in fact seem to be counting per-site, as I can change the site query parameter to any site on the network, and the count still decreases, as if this is not in fact measured per site, but instead, network-wide:


As an aside, I don't believe I'll need an API key, since the app I'm building makes requests on behalf of each individual user, and since I really don't picture ever hitting the 300 daily cap since I'm caching the data in chrome.storage.local.

This assumes, of course, that the 300 cap is in fact a daily cap and not a lifetime cap. Otherwise, my users would be able to use this for a limited time, until their own lifetime quotas have been exceeded.

Is this a bug, or am I going to need to use even heavier caching, like writing data to a file on the users' filesystems? (euuuuughh - shivers at the thought...)

Two days later, I checked my quota again by hitting the API. It now says 299 out of 300, so it looks like it's been reset. It's currently Nov 8, 7:38 AM UTC, so I'll wait until it rolls over again and do another test.

It's now currently Nov 9, 6:25 AM UTC, and I just hit the API for the first time since my last edit, and I have 297 out of 300 remaining. Is this a bug, or does the quota not reset every 24 hours as documented?

Today is Nov 10, 4:08 AM UTC, and hitting the API today results in a refreshed quota. It does reset, but it doesn't appear to be resetting every 24 hours at 12:00 AM UTC.

  • 4
    I just encountered this. It was reset some time between 2015-01-31T20:02:45.579Z and 2015-01-31T20:06:00.431Z for me today. It's a bit hard to schedule the API requests when you don't know at what time it is reset... Commented Jan 31, 2015 at 20:12

2 Answers 2


Update: Evidence now suggests that the API quota rolls over at a unique time for each app. 24 hours after that app-key, plus IP, combination made its first API call.
See this chat message.

The quota does reset every 24 hours, but the time seems to wander is custom for every app-instance. Some years ago, I seem to remember it resetting around midnight UTC, but it doesn't anymore.

Recently, the SmokeDetector bot started logging when its quota reset. Here are the logged times so far:

Day and Time (UTC)      Log entry
------------------      --------------
Dec 23  6:04 PM         API quota rolled over with 2001 requests remaining.
Dec 22  6:04 PM         API quota rolled over with 2014 requests remaining.
Dec 21  6:04 PM         API quota rolled over with 2851 requests remaining.
Dec 20  6:04 PM         API quota rolled over with 4665 requests remaining.
Dec 19 11:36 AM         API quota rolled over with 2580 requests remaining.
Dec 18 11:36 AM         API quota rolled over with 2824 requests remaining.
Dec 17  ???             Site + API + Bot glitch.  Rollover not certain.
Dec 16  5:06 PM         API quota rolled over with 1030 requests remaining.
Dec 15  5:05 PM         API quota rolled over with  900 requests remaining.
Dec 14  5:05 PM         API quota rolled over with 1896 requests remaining.
Dec 13  5:05 PM         API quota rolled over with 5506 requests remaining.
Dec 12  5:05 PM         API quota rolled over with 4118 requests remaining.
Dec 11  5:05 PM         API quota rolled over with 2598 requests remaining.
Dec 10  5:05 PM         API quota rolled over with 1640 requests remaining.
Dec  9  5:05 PM         API quota rolled over with 1624 requests remaining.
Dec  8  5:04 PM         API quota rolled over with 1981 requests remaining.
Dec  7  5:04 PM         API quota rolled over with 2866 requests remaining.
Dec  6  5:04 PM         API quota rolled over with 4596 requests remaining.

As you can see, the reset times tend to stay constant for a few days, then jump to a new time, then stay constant again. A "punctuated equilibrium".
We've yet to ascertain any rhyme or reason to it.
We now know that the time changes correspond with changes to the IP/server that the app was running on.


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.

You must log in to answer this question.

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