Les limites et les quotas protègent l'infrastructure Google contre un processus automatisé qui utilise l'API Email Audit de manière inappropriée. Les requêtes excessives provenant d'une API peuvent provenir d'une faute de frappe inoffensive ou d'un système inefficace qui effectue des appels d'API inutiles. Quelle que soit la cause, il est nécessaire de bloquer le trafic provenant d'une source spécifique lorsqu'il atteint un certain niveau pour assurer le bon fonctionnement global du système Google Workspace. Les limites permettent de garantir que les actions d'un développeur ne peuvent pas avoir d'impact négatif sur la communauté au sens large.
Dans le cas peu probable d'échec de votre requête API, vous recevrez une réponse de code d'état HTTP. Le code d'état 403 contient des informations sur les erreurs de saisie. Le code d'état HTTP 503 contient des informations sur les erreurs de dépassement des quotas d'API. 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 déterminé, envoyez-les en parallèle ou utilisez plusieurs threads dans votre application Java ou C#. Par exemple, au lieu d'ajouter ou de supprimer simultanément de nombreux e-mails d'un même utilisateur, vous pouvez demander l'envoi de petits messages à différents utilisateurs. Dans le cas des fils de discussion, essayez de commencer avec 10 fils (un par e-mail d'utilisateur). Notez que la recommandation de fil de discussion présente des compromis et n'est pas utile dans toutes les situations de l'API. Si le nombre de requêtes devient trop élevé, des erreurs de quota se produisent. Autre exemple de compromis : le quota de l'API Email Audit pour le taux global d'importation de messages maximal. Le débit d'importation correspond à une requête API (par seconde) et par utilisateur, quel que soit le nombre de threads effectuant des requêtes d'importation.
Pour toutes les erreurs temporelles (maximum N éléments pendant N secondes par thread), en particulier les erreurs de code d'état 503, nous vous recommandons d'intercepter l'exception et, en utilisant un algorithme d'intervalle exponentiel entre les tentatives, d'attendre un court délai avant de relancer 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 modèle pour les autres threads. Si la deuxième requête n'aboutit pas, votre application doit réduire la fréquence de la requête jusqu'à ce qu'un appel aboutisse.
Par exemple, augmentez le délai initial de cinq secondes à 10 secondes, puis réessayez votre appel ayant échoué. Définissez également une limite de nouvelle tentative. 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 d'API limitées | Limites |
|---|---|
| Fichiers chiffrés de la boîte aux lettres, création | La création des fichiers de boîte aux lettres chiffrés peut prendre plusieurs jours, selon la taille. |
| Fichiers de boîtes aux lettres chiffrés ; erreurs de suppression | Lorsque Supprimer une boîte aux lettres chiffrée et que des erreurs se produisent, la requête reçoit l'état MARKED_DELETE. Ces résumés et fichiers d'exportation sont automatiquement supprimés par Google dans un délai de 24 heures (avec les éventuels fichiers restants). Si l'état de MARKED_DELETE est régulièrement renvoyé, essayez une stratégie d'intervalle exponentiel entre les tentatives.
|
Le tableau suivant répertorie les quotas de l'API Email Audit:
| Catégories de quotas d'API | Quotas |
|---|---|
| Jetons d'authentification ClientLogin | Valable pendant 24 heures. L'erreur est 401 token expired.
|
| Formats de date | Convertissez toutes les dates au format UTC coordonné universel (UTC) avant de les utiliser avec l'API Email Audit. Pour en savoir plus, consultez la section Convertisseur UTC. |
Fichiers chiffrés de la boîte aux lettres, EXPIRED résumés et fichiers d'exportation
|
Google conserve les fichiers chiffrés de la boîte aux lettres pendant trois semaines. Passé ce délai, ils sont supprimés. Il incombe à l'administrateur du domaine de télécharger les fichiers de la boîte aux lettres dans le délai indiqué. |
| Fichiers chiffrés de la boîte aux lettres, format | Les fichiers de boîte aux lettres chiffrés sont au format mbox. |
| Fichiers de boîtes aux lettres chiffrés, nombre maximal de demandes de création | Le nombre maximal autorisé de requêtes de création par jour pour l'exportation de boîtes aux lettres est de 100 requêtes, en provenance de tous les administrateurs du domaine. |
| État chiffré du fichier de boîte aux lettres, pagination | Lorsque vous demandez l'état de toutes les requêtes 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, chaque page contenant 100 entrées au maximum et un URI dans une balise link rel='next' renvoyant vers la page de résultats suivante. Lorsque vous développez votre application cliente, votre code doit gérer ces résultats supplémentaires.
|
| Surveillance des e-mails | Le nombre de requêtes de surveillance des e-mails par jour est limité à 1 500. Cette limite s'applique au domaine et inclut toutes les requêtes 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). Il s'agit d'une clé de chiffrement RSA encodée en ASCII, au format PGP. 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 lisible avec le jeu de caractères US-ASCII (nom de jeu de caractères IANA à utiliser pour ASCII). |
| Recherche… | Les paramètres searchQuery et includeDeleted s'excluent mutuellement. Une requête de recherche n'est pas possible si includeDeleted="true".
|