Skip to main content
Mention sending the access_token with all requests.
Source Link
Makyen
  • 1.7k
  • 1
  • 12
  • 20

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.

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.

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.
Source Link
Makyen
  • 1.7k
  • 1
  • 12
  • 20

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.