Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
Las cuotas protegen la infraestructura de Google de los procesos automatizados que utilizan la API de Google Bid Manager de forma inapropiada. Garantizan que las acciones de un desarrollador no puedan afectar negativamente a la comunidad en general.
Límites de cuota
Todos los recursos y métodos de la API de Bid Manager comparten los siguientes límites predeterminados de cuota.
En la Consola de API de Google, esta cuota se conoce como Consultas por minuto por usuario y se establece en 240.
Se superaron los límites de cuota
En el caso improbable de que la solicitud falle debido a que se superó un límite de cuota, la API mostrará un código de estado HTTP y el motivo del error. Además, el cuerpo de la respuesta contiene una descripción detallada de lo que causó el error. Consulta la guía de Mensajes de error para ver una respuesta de error de ejemplo.
En la siguiente lista, se muestran los posibles errores y las acciones recomendadas para las fallas en las solicitudes a causa de exceder los límites de cuota.
Código
Motivo
Mensaje
Acción recomendada
403
dailyLimitExceeded
Se superó el límite diario
No vuelvas a intentar la operación sin solucionar el problema. Examina tu uso en la Consola de API de Google y modifica tu flujo de trabajo para realizar menos solicitudes. Puedes solicitar una cuota adicional si consideras que el uso es razonable.
403
userRateLimitExceeded
Se superó el límite de frecuencia de usuarios
Reduce la velocidad a la que envías las solicitudes con la retirada exponencial.
¿Qué es la retirada exponencial?
La retirada exponencial es una estrategia estándar de manejo de errores para aplicaciones de red en la que el cliente reintenta de forma periódica una solicitud con errores durante un período creciente. Si el servidor presenta errores debido a un gran volumen de solicitudes o tráfico de red, la retirada exponencial puede ser una buena estrategia para manejar estos errores. Por el contrario, esta estrategia no se recomienda para lidiar con errores que no estén relacionados con el volumen de la red o los tiempos de respuesta, como credenciales de autorización no válidas o errores de archivos no encontrados.
Si se la utiliza de forma correcta, la retirada exponencial aumenta la eficiencia del uso del ancho de banda, reduce la cantidad de solicitudes que se requieren para obtener una respuesta correcta y maximiza la capacidad de procesamiento de las solicitudes en entornos simultáneos.
A continuación, se muestra el flujo para implementar una retirada exponencial simple:
Realizar una solicitud a la API
Recibir una respuesta HTTP 503, que indica que debes reintentar la solicitud
Esperar 1 segundo + random_number_milliseconds y reintentar la solicitud
Recibir una respuesta HTTP 503, que indica que debes reintentar la solicitud
Esperar 2 segundos + random_number_milliseconds y reintentar la solicitud
Recibir una respuesta HTTP 503, que indica que debes reintentar la solicitud
Esperar 4 segundos + random_number_milliseconds y reintentar la solicitud
Recibir una respuesta HTTP 503, que indica que debes reintentar la solicitud
Esperar 8 segundos + random_number_milliseconds y reintentar la solicitud
Recibir una respuesta HTTP 503, que indica que debes reintentar la solicitud
Esperar 16 segundos + random_number_milliseconds y reintentar la solicitud
Detenerse. Informar o registrar un error
En el flujo anterior, random_number_milliseconds es una cantidad aleatoria de milisegundos menor o igual que 1,000. Esta es necesaria, ya que agregar un pequeño retraso aleatorio ayuda a distribuir la carga de manera más uniforme y a evitar la posibilidad de marcar el servidor. El valor de random_number_milliseconds se debe volver a definir tras cada espera.
Nota: La espera siempre es (2 ^ n) + random_number_milliseconds, en la que n es un número entero, que crece de forma monotónica, definido en un inicio como 0. El número entero n aumenta de a 1 por cada iteración (cada solicitud).
El algoritmo está configurado para terminar cuando n sea 5. Este límite impide que los clientes reintenten las solicitudes de forma infinita y genera una demora total de alrededor de 32 segundos antes de que una solicitud se considere “un error irrecuperable”. Un límite de reintentos mayor es aceptable, sobre todo si hay una carga larga en progreso. Solo asegúrate de limitar la demora de reintentos a un valor razonable, por ejemplo, menos de un minuto.
Solicita una cuota diaria adicional
Si crees que tu aplicación requiere una cuota diaria adicional, puedes seguir las instrucciones que se indican a continuación para solicitar más.
Las siguientes instrucciones solo se aplican a los proyectos que encontraron un error dailyLimitExceeded. Las acciones recomendadas para otros errores de cuota se abordan en la tabla anterior.
Revisa las estadísticas de uso en la página Métricas para asegurarte de que tu aplicación tenga el comportamiento esperado. Presta mucha atención a los métodos a los que se llamó y aborda cualquier uso inesperado o excesivo antes de continuar.
Si el uso parece normal, ve a la página Cuotas, haz clic en el ícono de edición junto a Consultas por día y en el vínculo "Solicitar una cuota mayor".
Asegúrate de revisar la información y seguir las instrucciones incluidas en el formulario de solicitud de cuota antes de enviar una solicitud de aumento.
[null,null,["Última actualización: 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."]]
