Limites d'utilisation

L'API Google Docs étant un service partagé, nous appliquons des quotas et des limites pour nous assurer qu'elle est utilisée de manière équitable par tous les utilisateurs et pour protéger l'état général du système Google Workspace.

Si vous dépassez un quota, vous recevrez généralement un 429: Too many requests code d'état HTTP. Dans ce cas, vous devez utiliser un algorithme d'intervalle exponentiel entre les tentatives et réessayer plus tard.

Le tableau suivant détaille les limites de requêtes :

Quotas
Requêtes de lecture
Par minute et par projet 3000
Par minute, par utilisateur et par projet 300
Requêtes d'écriture
Par minute et par projet 600
Par minute, par utilisateur et par projet 60

Résoudre les erreurs de quota basées sur le temps

Pour toutes les erreurs basées sur le temps (maximum de N requêtes par X minutes), nous vous recommandons de faire en sorte que votre code intercepte l'exception et utilise un intervalle exponentiel entre les tentatives tronqué pour vous assurer que vos appareils ne génèrent pas de charge excessive.

L'intervalle exponentiel entre les tentatives est une stratégie standard de traitement d'erreurs pour les applications réseau. Un algorithme d'intervalle exponentiel entre les tentatives relance les requêtes en augmentant de manière exponentielle le temps d'attente entre les requêtes jusqu'à ce que la durée maximale de l'intervalle soit atteinte. Si les requêtes échouent toujours, il est important que les délais entre les requêtes augmentent au fil du temps jusqu'à ce que la requête aboutisse.

Exemple d'algorithme

Un algorithme d'intervalle exponentiel entre les tentatives relance les requêtes de manière exponentielle, en augmentant le temps d'attente entre les tentatives jusqu'à ce que la durée maximale de l'intervalle exponentiel soit atteinte. Exemple :

  1. Envoyez une requête à l'API Google Docs.
  2. Si la requête échoue, attendez 1 + random_number_milliseconds, puis relancez la requête.
  3. Si la requête échoue, attendez 2 + random_number_milliseconds, puis relancez la requête.
  4. Si la requête échoue, attendez 4 + random_number_milliseconds, puis relancez la requête.
  5. Poursuivez ainsi jusqu'à atteindre la valeur maximum_backoff.
  6. Continuez à attendre et à réessayer jusqu'à un nombre maximal de tentatives, mais n'augmentez pas le délai d'attente entre les tentatives.

où :

  • Le temps d'attente est min(((2^n)+random_number_milliseconds), maximum_backoff), avec n incrémenté de 1 pour chaque itération (requête).
  • random_number_milliseconds est un nombre aléatoire de millisecondes inférieur ou égal à 1 000. Cela permet d'éviter les cas où de nombreux clients se retrouvent synchronisés pour une raison quelconque et effectuent tous une nouvelle tentative en même temps, en envoyant des requêtes par vagues synchronisées. La valeur de random_number_milliseconds est recalculée après chaque nouvelle tentative.
  • La valeur maximum_backoff est généralement définie sur 32 ou 64 secondes. La valeur appropriée dépend du cas d'utilisation.

Le client peut continuer à réessayer une fois qu'il a atteint la durée maximum_backoff. Au-delà de ce point, il n'est pas nécessaire de continuer à augmenter la durée de l'intervalle exponentiel entre les tentatives. Par exemple, si un client utilise une durée maximum_backoff de 64 secondes, il peut réessayer toutes les 64 secondes une fois cette valeur atteinte. À un moment donné, les clients doivent être empêchés de réessayer indéfiniment.

Le temps d'attente entre les nouvelles tentatives et le nombre de tentatives dépendent de votre cas d'utilisation et des conditions du réseau.

Tarifs

L'utilisation standard de l'API Google Docs est disponible sans frais supplémentaires. Le dépassement des limites de requêtes de quota devrait entraîner des frais sur votre compte de facturation Google Cloud plus tard en 2026. Pour en savoir plus, consultez Modèle standardisé Google Workspace pour les outils et les API d'agent.

Demander une augmentation du quota

Selon l'utilisation des ressources de votre projet, vous pouvez demander un ajustement de quota. Les appels d'API effectués par un compte de service sont considérés comme utilisant un seul compte. La demande d'ajustement de quota ne garantit pas l'approbation. Les demandes d'ajustement de quota qui augmenteraient considérablement la valeur du quota peuvent nécessiter plus de temps pour être approuvées.

Tous les projets ne sont pas soumis aux mêmes quotas. À mesure que votre utilisation de Google Cloud s'accroît, vos valeurs de quota peuvent devoir augmenter. Si vous prévoyez une augmentation significative de votre utilisation, vous pouvez anticiper cette évolution en demandant des ajustements de quotas sur la page Quotas et limites du système de la console Google Cloud.

Pour en savoir plus, consultez les ressources suivantes :

Quotas du serveur MCP Docs

Le serveur MCP Docs utilise des métriques de requêtes de lecture et d'écriture. Les tableaux suivants détaillent les quotas et le coût des requêtes pour chaque Docs serveur MCP method par section :

Quotas MCP Docs

Deux types de quotas sont appliqués :

  • Par minute et par projet : il s'agit du nombre de requêtes que votre projet Google Cloud peut effectuer en une minute.
  • Par minute, par utilisateur et par projet : il s'agit du nombre de requêtes qu'un utilisateur particulier peut effectuer dans votre projet Cloud.

Le tableau suivant détaille ces quotas :

Quotas
Requêtes de lecture
Par minute et par projet 3 000
Par minute, par utilisateur et par projet 300
Requêtes d'écriture
Par minute et par projet 600
Par minute, par utilisateur et par projet 60

Quotas de l'ensemble d'outils MCP Docs

Le tableau suivant détaille le coût des requêtes pour chaque docsmcp.googleapis.com ensemble d'outils :

Point de terminaison Outil Coût des requêtes
/mcp/v1 read_doc 1 requête de lecture
update_doc 1 requête d'écriture

Pour en savoir plus, consultez la documentation de référence de l'API MCP Docs .