For example, let's say client X signs into an app that I made. My servers get an access_token which I can then use to send requests on their behalf, for example reading their reputation history. By the nature of the app, it would send a few requests to the API using their access_token.

I do understand that if my app runs into any rate limits, the client ID can be used to identify that it's my app misbehaving, and not the client. But in a normal scenario, would any requests to the API using the supplied access token be counted towards the user's 10k quota? In other words, will my app's 10k quota decrease because of requests regarding authenticated users?

1 Answer 1


If you are using an access_token in a request to the SE API, then the quota which that request is counted against is the 10k requests/day for that user+application pair. Each user can have up to five 10k requests/day user+application pair quota bins. Those five 10k requests/day user+application pair quota bins are in addition to the 10k requests/day per IP address quota, which is the quota that's used for all accesses from a specific IP address which don't include an access_token value in the request. I assume that the 10k requests/day per IP address quota is also used when the user has exceeded the maximum of five user+application pair bins in that day, but I haven't tested to see exactly what actually happens.

For a different statement of the above, see the SE API documentation: Throttles.

To restate: Any requests to the SE API which are made using the same access_token are counted against the 10k requests/day quota for the user+application pair, regardless of from where the request was made.

  1. For all quotas above, "day" is actually a 24 hour period which starts when the first request is made which is applicable to that quota (perhaps group of quotas) when there isn't a currently active 24 hour period for that quota. In other words, the 24 hours for every quota isn't tied to any particular global time, but is tied to when accesses were first made for that quota when there wasn't a currently active quota. As an example, if the first request counted against that quota was sent at 2:38 PM, then the "day" is from 2:38 PM that day to 2:37:59.999 PM the next calendar day. If after 2:37:59.999 PM on the next calendar day, the first request for that quota was made at 7:52 PM, then the next 24 hour quota period is from 7:52 PM to 7:51:59.999 PM on the following day.
  2. It's unclear to me if the 10k requests/day for a user+application pair are really per user+application pair or per active access_token. In other words, I haven't tested to see if an application with more than one access_token for a particular user uses the same quota for all of the access_token values. While the wording in the documentation indicates that all access_token values for that user+application pair would share the same quota, I could see Stack Exchange writing the actual code either way.
  3. The separate 10k requests/day per user+application pair quota is a significant reason why you will probably want to send the access_token with all requests for that user, even for requests which don't need an access_token in order to function (e.g. read accesses which aren't getting privileged data). If you don't send the access_token with those requests, then the requests will be counted against the 10k requests/day/IP address quota.
  • So if client X were to have authenticated with only 3 apps including mine, then each app would have 10k requests/day for that specific user? And any other users (ex. client Y) of my app would have their own 10k requests/day limit? Commented Nov 21, 2022 at 3:18
  • @LakshyaRaj Yes, assuming client Y had also authenticated and an access_token was being used.
    – Makyen
    Commented Nov 21, 2022 at 3:21
  • That's great! Thanks for the quick and detailed answer. :) Commented Nov 21, 2022 at 3:22
  • 1
    @LakshyaRaj I'm glad I was able to help. I should point out that I added a 3rd note that just mentions that you'll probably want to send the access_token with all requests for that user, including the requests which don't actually need the access_token to function. You probably already realized that, but it's something that I've seen people not think about when the request doesn't actually need the access_token to function.
    – Makyen
    Commented Nov 21, 2022 at 3:29
  • Noted. I had intended to do so anyways, but I can easily see someone forgetting about that access token to keep off the 10k rq/day/ip limit. TY for the additional note! Commented Nov 21, 2022 at 3:34

You must log in to answer this question.

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