Les limites et les quotas protègent l'infrastructure Google contre les processus automatisés qui utilisent l'API Email Audit de manière inappropriée. Les requêtes excessives provenant d'une API peuvent être dues à une simple faute de frappe ou à un système mal conçu qui appelle inutilement l'API. Quelle qu'en soit la cause, il est nécessaire de bloquer le trafic provenant d'une source spécifique dès qu'il atteint un certain niveau afin de préserver l'état global du système Google Workspace. Les limites permettent de s'assurer que les actions d'un développeur n'ont pas d'impact négatif sur la communauté au sens large.
Dans le cas peu probable où votre requête API échouerait, vous recevrez un code d'état HTTP en réponse. Le code d'état 403 contient des informations sur les erreurs liées à des entrées incorrectes, tandis que le code d'état HTTP 503 contient des informations sur les erreurs indiquant les quotas d'API qui ont été dépassés. Ces réponses permettent à votre application personnalisée de détecter ces erreurs et de prendre les mesures appropriées.
Si vos requêtes doivent être traitées dans un délai fixe, envoyez-les en parallèle ou utilisez plusieurs threads dans votre application Java ou C#. Par exemple, vous pouvez demander de petits lots d'e-mails provenant de différents utilisateurs plutôt que d'ajouter ou de supprimer simultanément de nombreux e-mails d'un même utilisateur. Dans le cas des threads, essayez de commencer par 10 threads, un thread par adresse e-mail d'utilisateur. Notez que la recommandation de thread présente des compromis et n'est pas utile dans toutes les situations d'API. Si le nombre de requêtes devient trop élevé, des erreurs de quota se produisent. Un autre exemple de compromis est le quota de l'API Email Audit pour le taux maximal global d'importation de messages. Le taux d'importation est d'une requête API par seconde et par utilisateur, quel que soit le nombre de threads qui envoient des requêtes d'importation.
Pour toutes les erreurs basées sur le temps (maximum de N éléments pour N secondes par thread), en particulier les erreurs de code d'état 503, nous vous recommandons que votre code intercepte l'exception et, en utilisant un algorithme de rétrogradation exponentielle, attende un court délai avant de réessayer l'appel ayant échoué. Un exemple d'API Email Audit pour un thread consiste à attendre cinq secondes et à réessayer l'appel ayant échoué. Si la requête aboutit, répétez ce schéma pour les autres threads. Si la deuxième requête échoue, votre application doit réduire la fréquence des requêtes jusqu'à ce qu'un appel réussisse. Par exemple, augmentez le délai initial de cinq secondes à dix secondes, puis réessayez d'effectuer l'appel qui a échoué. Définissez également une limite de nouvelles tentatives. Par exemple, relancez une requête cinq à sept fois avec des délais différents avant que votre application ne renvoie une erreur à l'utilisateur.
Le tableau suivant répertorie les limites de l'API Email Audit :
| Catégories de limites d'API | Limites |
|---|---|
| Création de fichiers de boîte aux lettres chiffrés |
La création de fichiers de boîte aux lettres chiffrés peut prendre jusqu'à plusieurs jours, selon leur taille. |
| Fichiers de boîte aux lettres chiffrés, erreurs de suppression |
Lors de la suppression d'une boîte aux lettres chiffrée, si des erreurs se produisent, la requête reçoit l'état |
Le tableau suivant répertorie les quotas pour l'API Email Audit :
| Catégories de quotas d'API | Quotas |
|---|---|
| Jetons d'authentification ClientLogin |
Valable pendant 24 heures. L'erreur est |
| Formats de date |
Convertissez toutes les dates au format UTC (temps universel coordonné) avant de les utiliser avec l'API Email Audit. Pour en savoir plus, consultez Convertisseur UTC. |
|
Fichiers de boîte aux lettres chiffrés, résumés |
Google conserve les fichiers de boîte aux lettres chiffrés pendant trois semaines. Passé ce délai, elles sont supprimées. Il incombe à l'administrateur du domaine de télécharger ces fichiers de boîte aux lettres pendant cette période. |
| Fichiers de boîte aux lettres chiffrés, format |
Les fichiers de boîte aux lettres chiffrés sont au format mbox. |
| Fichiers de boîte aux lettres chiffrés, nombre maximal de demandes de création |
Le nombre maximal de demandes de création d'exportations de boîtes aux lettres par jour est de 100 pour l'ensemble des administrateurs du domaine. |
| État du fichier de boîte aux lettres chiffrée, pagination |
Lorsque vous demandez l'état de toutes les demandes de boîte aux lettres, les réponses peuvent renvoyer de grandes quantités de données. L'API Email Audit regroupe ces données dans des pages contenant chacune un maximum de 100 entrées, ainsi qu'un URI dans une balise |
| Surveillance des e-mails |
Le nombre maximal de demandes de surveillance d'adresses e-mail par jour est de 1 500. Cette limite s'applique au domaine et inclut toutes les demandes effectuées par un administrateur au cours de la journée. |
| Clé publique |
L'API Email Audit n'accepte qu'une seule clé. La clé publique utilise le logiciel GNU Privacy Guard (GPG). Elle est au format PGP et constitue une clé de chiffrement RSA encodée en ASCII. Avant d'importer la clé publique, vous devez d'abord la convertir en chaîne encodée en base64. Le fichier de clé publique doit être lu avec le jeu de caractères US-ASCII (nom de jeu de caractères IANA préféré pour ASCII). |
| Recherche |
Les paramètres |