Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
As cotas protegem a infraestrutura do Google de processos automatizados que usam a API Google Bid Manager de maneira inadequada. Elas garantem que as ações de um desenvolvedor não afetem negativamente a comunidade em geral.
Limites de cota
Os seguintes limites de cota padrão são compartilhados por todos os recursos e métodos da API Bid Manager.
No Console de APIs do Google, essa cota é chamada de consultas por minuto e usuário e está definida como 240.
Limites de cota excedentes
No caso improvável de a sua solicitação falhar por exceder um limite de cota, a API retorna um código de status HTTP e o motivo do erro. Além disso, o corpo da resposta vai conter uma descrição detalhada do que causou o erro. Consulte o guia Mensagens de erro para ver um exemplo de resposta de erro.
A lista a seguir mostra os possíveis erros e as ações recomendadas para falhas de solicitação causadas pelo excesso de limites de cota.
Código
Motivo
Mensagem
Ação recomendada
403
dailyLimitExceeded
Limite diário excedido
Não tente novamente sem resolver o problema. Analise o uso do Console de APIs do Google e modifique seu fluxo de trabalho para fazer menos solicitações. É possível solicitar uma cota adicional se você acredita que seu uso é razoável.
A espera exponencial é uma estratégia padrão de tratamento de erros para aplicativos de rede em que o cliente repete periodicamente uma solicitação com falha ao longo de um período crescente. Se um alto volume de solicitações ou o tráfego de rede intenso faz com que o servidor retorne erros, a espera exponencial pode ser uma boa estratégia para tratar esses erros. Por outro lado, essa não é uma estratégia relevante para tratar erros não relacionados ao volume de rede ou a tempos de resposta, como credenciais de autorização inválidas ou erros de arquivo não encontrado.
Usada corretamente, a espera exponencial aumenta a eficiência do uso da largura de banda, reduz o número de solicitações necessárias para conseguir uma resposta bem-sucedida e maximiza a capacidade de solicitações em ambientes simultâneos.
O fluxo para implementação da espera exponencial simples é o seguinte:
Faça uma solicitação para a API.
Receba uma resposta HTTP 503, que indica que você precisa repetir a solicitação.
Aguarde um segundo + random_number_milliseconds e envie novamente a solicitação.
Receba uma resposta HTTP 503, que indica que você precisa repetir a solicitação.
Aguarde dois segundos + random_number_milliseconds e envie novamente a solicitação.
Receba uma resposta HTTP 503, que indica que você precisa repetir a solicitação.
Aguarde 4 segundos + random_number_milliseconds e repita a solicitação.
Receba uma resposta HTTP 503, que indica que você deve repetir a solicitação.
Aguarde 8 segundos + random_number_milliseconds e repita a solicitação.
Receba uma resposta HTTP 503, que indica que você deve repetir a solicitação.
Aguarde 16 segundos + random_number_milliseconds e repita a solicitação.
Pare. Informe ou registre um erro.
No fluxo acima, random_number_milliseconds é um número aleatório de milissegundos menor ou igual a 1.000. Isso é necessário, uma vez que a introdução de um pequeno atraso aleatório ajuda a distribuir a carga de maneira mais uniforme e evitar a possibilidade de falha do servidor. Após cada espera, é preciso redefinir o valor de random_number_milliseconds.
Observação: a espera é sempre (2 ^ n) + random_number_milliseconds, em que n é um número inteiro monótono crescente inicialmente definido como 0. O número inteiro n é incrementado em 1 para cada iteração (cada solicitação).
O algoritmo é definido para terminar quando n for 5. Esse limite impede que os clientes fiquem tentando infinitamente e gera um atraso total de cerca de 30 segundos antes de uma solicitação ser considerada "um erro irrecuperável". Um número máximo maior de tentativas não é um problema, especialmente se um upload longo estiver em andamento. No entanto, use um atraso de repetição aceitável, por exemplo, menos de um minuto.
Como solicitar cota diária adicional
Se você acha que seu aplicativo precisa de uma cota diária adicional, pode solicitar um aumento da cota seguindo as instruções abaixo.
As instruções a seguir só se aplicam a projetos que encontraram um erro dailyLimitExceeded. As ações recomendadas para outros erros de cota são abordadas na tabela acima.
Revise suas estatísticas de uso na página Métricas para garantir que seu aplicativo esteja se comportando conforme o esperado. Preste muita atenção aos métodos que foram chamados e resolva usos inesperados ou excessivos antes de continuar.
Se o uso parecer normal, acesse a página Cotas, clique no ícone de edição ao lado de Consultas por dia e selecione o link "Inscrever-se para uma cota maior".
Leia as informações e siga as instruções incluídas no formulário de solicitação de cota antes de enviar uma solicitação de aumento.
[null,null,["Última atualização 2025-08-31 UTC."],[[["\u003cp\u003eGoogle Bid Manager API uses quotas to protect its infrastructure and ensure fair usage for all developers.\u003c/p\u003e\n"],["\u003cp\u003eDefault quota limits include 2,000 requests per project per day and 4 queries per second per project.\u003c/p\u003e\n"],["\u003cp\u003eExceeding quota limits results in specific error codes, requiring actions like reducing requests or using exponential backoff.\u003c/p\u003e\n"],["\u003cp\u003eExponential backoff is a retry strategy for handling temporary errors by gradually increasing wait times between requests.\u003c/p\u003e\n"],["\u003cp\u003eDevelopers can request additional daily quota through the Google API Console if needed.\u003c/p\u003e\n"]]],["Google Bid Manager API uses quotas to protect its infrastructure, limiting projects to 2,000 daily requests and 4 queries per second. Exceeding these results in errors; `dailyLimitExceeded` requires usage examination and possible quota increase, while `userRateLimitExceeded` needs rate slowdown via exponential backoff. Exponential backoff retries failed requests with increasing delays (e.g., 1, 2, 4 seconds) and randomized milliseconds, terminating after a set number of attempts. Additional daily quota can be requested through the Google API Console.\n"],null,["# 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.\n\nQuota limits\n------------\n\nThe following default quota limits are shared by all Bid Manager API resources and methods.\n\n- 2,000 requests per project per day - [can be increased](#additional_quota).\n- 4 queries per second (QPS) per project.\n - In the Google API Console this quota is referred to as **Queries per minute per user**, and is set to 240.\n\n| **Note:** Daily quotas refresh at midnight PST.\n\nExceeding quota limits\n----------------------\n\nIn 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](/bid-manager/core_errors) guide for an example error response.\n\nThe following list shows the possible errors and recommended actions for request failures caused by exceeding quota limits.\n\n| Code | Reason | Message | Recommended Action |\n|------|-----------------------|--------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| 403 | dailyLimitExceeded | Daily Limit Exceeded | Do not retry without fixing the problem. [Examine your usage](https://console.developers.google.com/project/_/apiui/apiview/doubleclickbidmanager/metrics) from the Google API Console and modify your workflow to make fewer requests. You can [request additional quota](#additional_quota) if you believe your usage is reasonable. |\n| 403 | userRateLimitExceeded | User Rate Limit Exceeded | Slow down the rate at which you are sending requests using [exponential backoff](#exponential_backoff). |\n\n#### What is exponential backoff?\n\nExponential 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.\n\nUsed 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.\n\nThe flow for implementing simple exponential backoff is as follows:\n\n1. Make a request to the API.\n2. Receive an `HTTP 503` response, which indicates you should retry the request.\n3. Wait 1 second + random_number_milliseconds and retry the request.\n4. Receive an `HTTP 503` response, which indicates you should retry the request.\n5. Wait 2 seconds + random_number_milliseconds, and retry the request.\n6. Receive an `HTTP 503` response, which indicates you should retry the request.\n7. Wait 4 seconds + random_number_milliseconds, and retry the request.\n8. Receive an `HTTP 503` response, which indicates you should retry the request.\n9. Wait 8 seconds + random_number_milliseconds, and retry the request.\n10. Receive an `HTTP 503` response, which indicates you should retry the request.\n11. Wait 16 seconds + random_number_milliseconds, and retry the request.\n12. Stop. Report or log an error.\n\nIn 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.\n\n**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).\n\nThe 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.\n\nRequesting additional daily quota\n---------------------------------\n\nIf you think that your application requires additional daily quota, you can request more by following the instructions below.\n\nThe following instructions only apply to projects that have encountered a `dailyLimitExceeded` error. Recommended actions for other quota errors are covered in the [table above](#exceeding_limits).\n\n1. Navigate to the [Bid Manager API](https://console.developers.google.com/project/_/apiui/apiview/doubleclickbidmanager/quotas) in the Google API Console.\n2. 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.\n3. 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\".\n\nMake sure to review the information and follow the instructions included in the quota request form before submitting an increase request.\n| **Note:** The email address you provide must be one that you actively monitor, as a representative may reach out to gather additional information."]]
