We are currently migrating a subset of report types from offline to instant reporting. Once a user is migrated, queries.list responses will include existing instant reports. See our blog post for more information.
Stay organized with collections
Save and categorize content based on your preferences.
Quotas protect Google's infrastructure from automated processes that use the Google Bid Manager API in an inappropriate way. They ensure that one developer's actions cannot negatively impact the larger community.
Quota limits
The following default quota limits are shared by all Bid Manager API resources and methods.
In the Google API Console this quota is referred to as Queries per minute per user, and is set to 240.
Exceeding quota limits
In the unlikely event that your request fails due to exceeding a quota limit, the API returns an HTTP status code and reason for the error. Additionally, the body of the response contains a detailed description of what caused the error. See the Error Messages guide for an example error response.
The following list shows the possible errors and recommended actions for request failures caused by exceeding quota limits.
Code
Reason
Message
Recommended Action
403
dailyLimitExceeded
Daily Limit Exceeded
Do not retry without fixing the problem. Examine your usage from the Google API Console and modify your workflow to make fewer requests. You can request additional quota if you believe your usage is reasonable.
403
userRateLimitExceeded
User Rate Limit Exceeded
Slow down the rate at which you are sending requests using exponential backoff.
What is exponential backoff?
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 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:
Make a request to the API.
Receive an HTTP 503 response, which indicates you should retry the request.
Wait 1 second + random_number_milliseconds and retry the request.
Receive an HTTP 503 response, which indicates you should retry the request.
Wait 2 seconds + random_number_milliseconds, and retry the request.
Receive an HTTP 503 response, which indicates you should retry the request.
Wait 4 seconds + random_number_milliseconds, and retry the request.
Receive an HTTP 503 response, which indicates you should retry the request.
Wait 8 seconds + random_number_milliseconds, and retry the request.
Receive an HTTP 503 response, which indicates you should retry the request.
Wait 16 seconds + random_number_milliseconds, and retry the request.
Stop. Report or log an error.
In the above flow, random_number_milliseconds is a random number of milliseconds less than or equal to 1000. This is necessary, since introducing a small random delay helps distribute the load more evenly and avoid the possibility of stampeding the server. The value of random_number_milliseconds must be redefined after each wait.
Note: The wait is always (2 ^ n) + random_number_milliseconds, where n is a monotonically increasing integer initially defined as 0. The integer n is incremented by 1 for each iteration (each request).
The algorithm is set to terminate when n is 5. This ceiling prevents clients from retrying infinitely, and results in a total delay of around 32 seconds before a request is deemed "an unrecoverable error." A larger maximum number of retries is fine, especially if a long upload is in progress; just be sure to cap the retry delay at something reasonable, say, less than one minute.
Requesting additional daily quota
If you think that your application requires additional daily quota, you can request more by following the instructions below.
The following instructions only apply to projects that have encountered a dailyLimitExceeded error. Recommended actions for other quota errors are covered in the table above.
Review your usage statistics from the Metrics page to ensure your application is behaving as expected. Pay close attention to the methods that have been called and address any unexpected or excessive usage before proceeding.
If usage looks normal, navigate to the Quotas page, click the edit icon next to Queries per day and click the link to "Apply for higher quota".
Make sure to review the information and follow the instructions included in the quota request form before submitting an increase request.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Missing the information I need","missingTheInformationINeed","thumb-down"],["Too complicated / too many steps","tooComplicatedTooManySteps","thumb-down"],["Out of date","outOfDate","thumb-down"],["Samples / code issue","samplesCodeIssue","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2024-08-21 UTC."],[],[]]