Understanding Gmail api quotas

Question

I have read the gmail api quota explanation here (https://developers.google.com/gmail/api/v1/reference/quota), but am still having troubles understanding what causes us to go over the limit.

Question 1: What is a user in a per user quota? I am not sure if the user is an individual gmail user, or a service client using the gmail api.

Question 2: We've seen the following error a few times, but don't see any obvious limit we've hit.

"error": {
 "errors": [
  {
   "domain": "usageLimits",
   "reason": "rateLimitExceeded",
   "message": "Rate Limit Exceeded"
  }
 ],
 "code": 429,
 "message": "Rate Limit Exceeded"
}

We were under 250 units/s and 25,000 units/100s. We're only using history.list and message.get calls no sending or modifications.
Is there some other quota I am missing?

Answer 1

1. User quota is based upon the account you are accessing. So it would be the GMail account. Sometimes you can trick it by sending a random quotaUser but this doesn't always work Google also uses your IP address to track quota I suspect.

2. User rate limit is flood protection you are going to fast.

Per User Rate Limit 250 quota units per user per second, moving average (allows short bursts)

Exceeding a rate limit will cause an HTTP 403 or HTTP 429 Too Many Requests response and your app should respond by retrying with exponential backoff.

Googles calculations are not perfect you could be sending more or less and still hit this quota. Just implementexponential backoff.

Exponential backoff

The flow for implementing simple exponential backoff is as follows:

1. Make a request to the API.
2. Receive an HTTP 403 rate-limited response, which indicates you should retry the request.
3. Wait 1 + random_number_milliseconds seconds and retry the request.
4. Receive an HTTP 403 rate-limited response, which indicates you should retry the request.
5. Wait 2 + random_number_milliseconds seconds, and retry the request.
6. Receive an HTTP 403 rate-limited response, which indicates you should retry the request.
7. Wait 4 + random_number_milliseconds seconds, and retry the request.
8. Receive an HTTP 403 rate-limited response, which indicates you should retry the request.
9. Wait 8 + random_number_milliseconds seconds, and retry the request.
10. Receive an HTTP 403 rate-limited response, which indicates you should retry the request.
11. Wait 16 + random_number_milliseconds seconds, and retry the request.
12. Stop. Report or log an error.