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?

Xylina

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.

Blida

so what's interesting is that the requests per day "quota" (requests per day) makes sense, I can do one list request and see a request "cost" of 5, however the per 100 seconds cost is really strange, if I do one request I see a cost of 8.333. This multiplier (1 ⅔) seems to apply to all services (APIs). Anyone have any ideas? – Bevbevan

that quota isnt perfect you can do 250 requests in 5 seconds and be ok but you can also do 240 and have it kick out. Dont try to thread the needle on that one. this is the closest i ever got daimto.com/google-apis-flood-buster – Blida

so I asked google support and they said that the per 100 seconds quotas are actually the per second quotas because of some reason that didn't really make sense. However the would not give me a straight answer on what the per second quotas were for each service. – Bevbevan

@DalmTo I've added a repo with my rate limiter here: github.com/thehesiod/rate-limiter – Bevbevan

@Bevbevan thats a great project you might want to give it a better description in the readme so others can find it. – Blida

@DalmTo in a serious lack of time, tracking this horrible leak when using the google python APIs :( – Bevbevan

Answer 2

For your Question 1

Here are the meaning of the different quota in your Gmail

• QPD(quota per day) - meaning the maximum numbers of request over a 24 hour period a client id is able to make to an API

• QPS(quota per second) - meaning a global quota per second for the application, meaning how many calls a second an application can make

• quota per seconds per user - meaning the number of queries a user, the application can make.

For question number 2

Well, if you check the Quota of Gmail in your developer console, the Gmail has a default quota of:

So what can I suggest you is to use the following tips so that you work with your quota efficiently:

• Push notification - it improve the performance of your application. It allows you to eliminate the extra network and compute costs involved with polling resources to determine if they have changed. Whenever a mailbox changes, the Gmail API notifies your backend server application.

• Use synchronization to retrieve and store as many of the most recent messages or threads as are necessary for your purpose.

• Batching Requests - to reduce the number of HTTP connections your client has to make.

If you notice that you reach this limit and you need more than this, then you can apply for more quota here.

Farlay