Page Summary
-
Google Ads API rate limits requests by queries per second (QPS) per client customer ID and developer token using a Token Bucket algorithm.
-
Rate limits prevent users from overwhelming API servers with high request volumes.
-
Requests exceeding rate limits receive a
RESOURCE_TEMPORARILY_EXHAUSTEDerror. -
Reducing the number of requests and throttling QPS from the client side can help mitigate rate limits.
-
Strategies to manage rate limits include limiting concurrent tasks, batching requests, implementing throttling and rate limiters, and using queueing.
The Google Ads API enforces rate limiting by queries per second (QPS) on both customer IDs and Google Cloud projects independently. The Google Ads API uses a token bucket algorithm to meter requests and determine an appropriate QPS limit, so the exact limit will vary depending on the overall server load at any given time.
The purpose of imposing rate limits is to prevent one user from disrupting service for other users by (either intentionally or unintentionally) overwhelming the Google Ads API servers with a high volume of requests.
Requests that are in violation of rate limits will be rejected with the error:
RESOURCE_TEMPORARILY_EXHAUSTED.
You can take control of your app and mitigate rate limits by both actively reducing the number of requests and throttling QPS from the client side.
There are a number of ways to reduce the chances of exceeding the rate limit. Becoming familiar with Enterprise Integration Patterns (EIP) concepts such as messaging, re-delivery, and throttling can help you build a more robust client app.
The following recommended practices ordered by complexity, with simpler strategies at the top and more robust but sophisticated architectures after:
Limit concurrent tasks
One root cause of exceeding rate limits is that the client app is spawning an excessive number of parallel tasks. While we don't limit the number of parallel requests a client app can have, this can exceed the requests per second limit at the Google Cloud project level.
Setting a reasonable upper bound for the total number of concurrent tasks that are going to make requests (across all processes and machines), and adjusting upward to optimize your throughput without exceeding the rate limit is recommended.
Furthermore, you can consider throttling QPS from the client side (check out Throttling and rate limiters).
Batching requests
Consider batching multiple operations into a single request. This is most
applicable on Mutate calls for various services. For example, if you're
updating status for multiple instances of AdGroupAd, you
can call MutateAdGroupAds once, and pass in
multiple operations instead of calling
MutateAdGroupAds once for each
AdGroupAd. Refer to our
batch operations guidance for some additional
examples.
While batching requests reduces the total number of requests and mitigates the rate limits on requests per minute, it may trigger the operations per minute rate limit if you perform a large number of operations against a single account.
Throttling and rate limiters
In addition to limiting the total number of threads in your application, you can also implement rate limiters on the client side. This can ensure all the threads across your processes and / or clusters are governed by a specific QPS limit from the client side.
You can check out Guava Rate Limiter, or implement your own token bucket based algorithm for a clustered environment. For example, you could generate tokens and store them in a shared transactional storage such as a database, and each client would have to acquire and consume a token before it processes the request. If the tokens were used up, the client would have to wait until the next batch of tokens is generated.
Queueing
A message queue is the solution for operation load distribution, while also controlling request and consumer rates. There are a number of message queue options available — some open source, some proprietary — and many of them can work with different languages.
When using message queues, you can have multiple producers pushing messages to the queue and multiple consumers processing those messages. Throttles can be implemented at the consumer side by limiting the number of concurrent consumers, or implement rate limiters or throttlers for either the producers or consumers.
For example, if a message consumer encounters a rates limit error, that consumer can return the request to the queue to be retried. At the same time, that consumer can also notify all other consumers to pause processing for a number of seconds to recover from the error.