Gmail API - Rate Limit Exceeded [429], Backend Error [500]

Question

We have an application that uses the Gmail API to access emails in Gmail.

Randomly we got the following error message

Google.Apis.Requests.RequestError Rate Limit Exceeded [429] Errors [ Message[Rate Limit Exceeded] Location[ - ] Reason[rateLimitExceeded] Domain[usageLimits] ]

Which we then retry in our code on error event and got

Google.Apis.Requests.RequestError Backend Error [500] Errors [ Message[Backend Error] Location[ - ] Reason[backendError] Domain[global] ]

which we then retry in our code on error event (we try 3 times) and it worked as expected.

There is some issue with the Gmail API backend here. we are making < 1000 Gmail API calls per day and nothing concurrent so I can't see that we have breached any limits.

Anybody else encountering this strange behaviour?

Here is the code that is being called

 UsersResource.MessagesResource.GetRequest gr = gs.Users.Messages.Get(emailAccount, msgId);
 {
        gr.Format = UsersResource.MessagesResource.GetRequest.FormatEnum.Raw;
        Message m = new Message();
        try
        {
            m = gr.Execute();
        }
 }

Answer 1

The Gmail API has the same daily usage limit that applies to all requests made from your application, as well as per-user rate limits.

• Daily Usage 1,000,000,000 quota units per day Per User Rate Limit
• 250 quota units per user per second, moving average (allows short bursts)

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

The 500 errors are server hiccups the server took to long to respond so it timed out your request. The solution for this is the same as the solution for the above error you should implement exponential backoff and try again.

Exponential backoff is a standard error handling strategy for network applications in which the client periodically retries a failed request over an increasing amount of time. If a high volume of requests or heavy network traffic causes the server to return errors, exponential backoff may be a good strategy for handling those errors. Conversely, it is not a relevant strategy for dealing with errors unrelated to rate-limiting, network volume or response times, such as invalid authorization credentials or file not found errors.

Used properly, exponential backoff increases the efficiency of bandwidth usage, reduces the number of requests required to get a successful response, and maximizes the throughput of requests in concurrent environments.

The flow for implementing simple exponential backoff is as follows.

1. Make a request to the API
2. Receive an error response that has a retry-able error code
3. Wait 1s + random_number_milliseconds seconds
4. Retry request
5. Receive an error response that has a retry-able error code
6. Wait 2s + random_number_milliseconds seconds
7. Retry request
8. Receive an error response that has a retry-able error code
9. Wait 4s + random_number_milliseconds seconds
10. Retry request
11. Receive an error response that has a retry-able error code
12. Wait 8s + random_number_milliseconds seconds
13. Retry request
14. Receive an error response that has a retry-able error code
15. Wait 16s + random_number_milliseconds seconds
16. Retry request
17. If you still get an error, stop and log the error.