Limites d'utilisation

L'API Google Chat étant un service partagé, nous appliquons des quotas et des limites pour garantir une utilisation équitable par tous les utilisateurs et protéger les performances globales de Google Workspace.

Si vous dépassez un quota, vous recevez une réponse avec le code d'état HTTP 429: Too many requests. Des vérifications de limite de débit supplémentaires sur le backend Chat peuvent également générer la même réponse d'erreur. Si cette erreur se produit, vous devez utiliser un algorithme d'intervalle exponentiel entre les tentatives et réessayer ultérieurement. Tant que vous respectez les quotas par minute indiqués dans les tableaux suivants, le nombre de requêtes que vous pouvez envoyer par jour n'est pas limité.

Deux types de quotas s'appliquent aux méthodes de l'API Chat: les quotas par espace et par projet.

Quotas par espace

Les quotas par espace limitent le taux de requêtes dans un espace donné. Ils sont partagés entre toutes les applications Chat intervenant dans cet espace, qui appellent les méthodes API Chat répertoriées pour chaque quota.

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

Quota par espace

Méthodes de l'API Chat

Limite (par tranche de 60 secondes,
partagée entre toutes les applications Chat de l'espace)

Lectures par minute

media.download

spaces.get

spaces.members.get

spaces.members.list

spaces.messages.get

spaces.messages.list

spaces.messages.attachments.get

spaces.messages.reactions.list

900

Écritures par minute

media.upload

spaces.delete

spaces.patch

spaces.messages.create (s'applique également aux webhooks entrants)

spaces.messages.delete

spaces.messages.patch

spaces.messages.reactions.create

spaces.messages.reactions.delete

60

Quotas par projet

Les quotas par projet limitent le taux de requêtes pour un projet Google Cloud. Ils s'appliquent donc à une seule application Chat qui appelle les méthodes de l'API Chat spécifiées pour chaque quota.

Le tableau suivant détaille les limites de requêtes par projet. Ces limites sont également disponibles sur la page Quotas.

Quota par projet

Méthodes de l'API Chat

Limite (pour 60 secondes)

Nombre d'écritures de messages par minute

spaces.messages.create

spaces.messages.patch

spaces.messages.delete

3 000

Nombre de messages lus par minute

spaces.messages.get

spaces.messages.list

3 000

Nombre d'écritures de membres par minute

spaces.members.create

spaces.members.delete

300

Nombre de lectures par minute

spaces.members.get

spaces.members.list

3 000

Espace écrit par minute

spaces.setup

spaces.create

spaces.patch

spaces.delete

60

Espaces lus par minute

spaces.get

spaces.list

spaces.findDirectMessage

3 000

Écritures de pièces jointes par minute

media.upload

600

Lectures de pièces jointes par minute

spaces.messages.attachments.get

media.download

3 000

Nombre d'écritures de réaction par minute

spaces.messages.reactions.create

spaces.messages.reactions.delete

600

Réactions lues par minute

spaces.messages.reactions.list

3 000

Limites d'utilisation supplémentaires

Des limites de quota supplémentaires s'appliquent pour la création d'espaces de type GROUP_CHAT ou SPACE (en utilisant la méthode spaces.create ou spaces.setup). Créez moins de 35 espaces par minute et 210 espaces par heure de ce type. Les espaces de type DIRECT_MESSAGE ne sont pas soumis à ces limites de quota supplémentaires.

Les requêtes volumineuses par seconde (RPS) provenant de toute API ciblant le même espace peuvent déclencher des limites internes supplémentaires qui ne sont pas visibles sur la page Quotas.

Résoudre les erreurs de quota temporelles

Pour toutes les erreurs temporelles (N requêtes maximum toutes les X minutes), nous vous recommandons d'intercepter l'exception par votre code et d'utiliser un intervalle exponentiel entre les tentatives tronqué pour vous assurer que vos appareils ne génèrent pas une charge excessive.

L'intervalle exponentiel entre les tentatives est une stratégie standard de traitement des exceptions pour les applications réseau. Un algorithme d'intervalle exponentiel entre les tentatives relance les requêtes en utilisant des temps d'attente croissants de manière exponentielle entre les requêtes, jusqu'à un intervalle maximal entre les tentatives. Si les requêtes échouent toujours, il est important que les délais entre les requêtes augmentent avec le temps jusqu'à ce qu'elles aboutissent.

Exemple d'algorithme

Un algorithme d'intervalle exponentiel entre les tentatives relance les requêtes de manière exponentielle, augmentant ainsi le temps d'attente entre les tentatives jusqu'à un intervalle maximal entre les tentatives. Exemple :

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

où :

  • Le temps d'attente est de 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 dans lesquels de nombreux clients sont synchronisés par une certaine situation 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 de requête.
  • 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 à effectuer de nouvelles tentatives après avoir atteint le délai 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 un délai maximum_backoff de 64 secondes, une fois cette valeur atteinte, il peut effectuer une nouvelle tentative toutes les 64 secondes. À un moment donné, les clients ne doivent pas pouvoir effectuer de nouvelles tentatives indéfiniment.

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

Demander une augmentation du quota par projet

En fonction de l'utilisation des ressources par votre projet, vous pouvez demander une augmentation de quota. Les appels d'API effectués par un compte de service sont considérés comme n'utilisant qu'un seul compte. La demande d'augmentation de quota ne garantit pas l'approbation. L'approbation des augmentations de quota importantes peut prendre plus de temps.

Tous les projets ne sont pas soumis aux mêmes quotas. À mesure que vous utilisez Google Cloud de plus en plus, vos quotas peuvent avoir besoin d'augmenter. Si vous prévoyez une augmentation notable de l'utilisation, vous pouvez anticiper cette évolution en demandant des ajustements de quota sur la page Quotas de la console Google Cloud.

Pour en savoir plus, consultez les ressources suivantes :