Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Les quotas protègent l'infrastructure de Google contre les processus automatisés qui utilisent l'API Google Bid Manager de manière inappropriée. Elles garantissent que les actions d'un développeur ne peuvent pas avoir d'impact négatif sur l'ensemble de la communauté.
Limites de quota
Les limites de quota par défaut suivantes sont partagées par toutes les ressources et méthodes de l'API Bid Manager.
2 000 requêtes par projet et par jour (possibilité d'augmenter le nombre de requêtes autorisées)
4 requêtes par seconde (RPS) par projet
Dans la console Google APIs, ce quota est appelé Requêtes par minute et par utilisateur, et il est défini sur 240.
Dépassement des limites de quota
Dans le cas peu probable où votre requête échouerait en raison du dépassement d'une limite de quota, l'API renverra un code d'état HTTP ainsi que le motif de l'erreur. De plus, le corps de la réponse contient une description détaillée de la cause de l'erreur. Consultez le guide Messages d'erreur pour obtenir un exemple de réponse d'erreur.
La liste suivante présente les erreurs possibles et les actions recommandées pour les échecs de requêtes causés par un dépassement des limites de quota.
Code
Motif
Message
Action recommandée
403
dailyLimitExceeded
Limite quotidienne dépassée
Ne relancez pas la requête avant d'avoir résolu le problème. Évaluez votre utilisation dans la console Google APIs et modifiez votre workflow pour réduire le nombre de requêtes. Vous pouvez demander un quota supplémentaire si vous pensez que votre utilisation est raisonnable.
Qu'est-ce que l'intervalle exponentiel entre les tentatives ?
L'intervalle exponentiel entre les tentatives est une stratégie standard en matière de traitement d'erreurs pour les applications réseau, selon laquelle le client relance périodiquement une requête ayant échoué sur une durée de plus en plus longue. Si un volume élevé de requêtes ou un trafic réseau important provoquent des erreurs sur le serveur, l'intervalle exponentiel entre les tentatives peut s'imposer comme une stratégie efficace pour traiter ces erreurs. À l'inverse, cette stratégie n'est pas pertinente pour traiter les erreurs sans rapport avec le volume réseau ou les temps de réponse, telles que les erreurs associées aux identifiants d'autorisation non valides ou aux fichiers introuvables.
Utilisé correctement, l'intervalle exponentiel entre les tentatives augmente l'efficacité de l'utilisation de la bande passante, réduit le nombre de requêtes nécessaires pour obtenir une réponse positive et optimise le débit des requêtes dans les environnements avec simultanéité.
Le fonctionnement de l'intervalle exponentiel simple entre les tentatives se présente comme suit :
Vous envoyez une requête à l'API.
Vous recevez une réponse HTTP 503, qui indique que vous devez relancer la requête.
Vous patientez 1 seconde + "random_number_milliseconds", puis vous relancez la requête.
Vous recevez une réponse HTTP 503, qui indique que vous devez relancer la requête.
Vous patientez 2 secondes + "random_number_milliseconds", puis vous relancez la requête.
Vous recevez une réponse HTTP 503, qui indique que vous devez relancer la requête.
Vous patientez 4 secondes + "random_number_milliseconds", puis vous relancez la requête.
Vous recevez une réponse HTTP 503, qui indique que vous devez relancer la requête.
Vous patientez 8 secondes + "random_number_milliseconds", puis vous relancez la requête.
Vous recevez une réponse HTTP 503, qui indique que vous devez relancer la requête.
Vous patientez 16 secondes + "random_number_milliseconds", puis vous relancez la requête.
Vous arrêtez, puis vous signalez ou consignez une erreur.
Dans le flux ci-dessus, "random_number_milliseconds" correspond à un nombre aléatoire de millisecondes inférieur ou égal à 1 000. Cette valeur est nécessaire, car l'introduction d'un petit délai aléatoire aide à répartir la charge de manière plus uniforme et à éviter la surcharge du serveur. La valeur de "random_number_milliseconds" doit être redéfinie après chaque temps d'attente.
Remarque : L'attente correspond toujours à (2 ^ n) + "random_number_milliseconds", où "n" est un entier augmentant de manière monotone défini initialement sur 0. L'entier "n" est augmenté de 1 pour chaque itération (chaque requête).
L'algorithme est configuré pour se terminer lorsque "n" vaut 5. Ce plafond empêche les clients d'effectuer des relances indéfiniment et entraîne un délai total d'environ 32 secondes avant qu'une requête ne soit considérée comme une "erreur non récupérable". Vous pouvez tout à fait définir un nombre maximal de tentatives plus élevé, surtout si une longue importation est en cours d'exécution. Veillez simplement à limiter le délai des nouvelles tentatives de manière raisonnable, par exemple à moins d'une minute.
Demander un quota quotidien supplémentaire
Si vous pensez que votre application nécessite un quota quotidien supplémentaire, vous pouvez en demander plus en suivant les instructions ci-dessous.
Les instructions suivantes ne s'appliquent qu'aux projets qui ont rencontré une erreur dailyLimitExceeded. Les actions recommandées pour les autres erreurs de quota sont décrites dans le tableau ci-dessus.
Examinez vos statistiques d'utilisation à partir de la page Métriques pour vous assurer que votre application fonctionne comme prévu. Portez une attention particulière aux méthodes appelées et corrigez toute utilisation inattendue ou excessive avant de continuer.
Si l'utilisation semble normale, accédez à la page Quotas, cliquez sur l'icône de modification à côté de Requêtes par jour, puis sur le lien "Demander un quota supérieur".
Veillez à consulter les informations et à suivre les instructions incluses dans le formulaire de demande de quota avant d'envoyer une demande d'augmentation.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/08/31 (UTC).
[null,null,["Dernière mise à jour le 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."]]
