Los límites y las cuotas protegen la infraestructura de Google de un proceso automatizado que usa la API de auditoría de correo electrónico de forma inapropiada. Las solicitudes excesivas de una API pueden deberse a un error tipográfico inofensivo o a un sistema de diseño ineficiente que realiza llamadas innecesarias a la API. Sin importar la causa, es necesario bloquear el tráfico de una fuente específica cuando alcanza un cierto nivel para el estado general del sistema de Google Workspace. Los límites ayudan a garantizar que las acciones de un desarrollador no tengan un impacto negativo en la comunidad.
En el caso improbable de que la solicitud a la API falle, recibirás una respuesta de código de estado HTTP. Un código de estado de 403
tiene información de error sobre una entrada incorrecta, y un código de estado HTTP de 503
tiene información de error que indica qué cuotas de API se superaron. Estas respuestas permiten que tu aplicación personalizada detecte estos errores y realice las acciones correspondientes.
Si tus solicitudes deben completarse en un período fijo, envíalas en paralelo o usa varios subprocesos en tu aplicación de Java o C#. Un ejemplo de solicitudes paralelas es solicitar lotes pequeños de correos electrónicos de diferentes usuarios, en lugar de agregar o quitar muchos correos electrónicos de un usuario a la vez. En el caso de las conversaciones, intenta comenzar con 10 conversaciones; una por cada correo electrónico de usuario. Ten en cuenta que las recomendaciones de subprocesos tienen compensaciones y no son útiles para todas las situaciones de API. Si la cantidad de solicitudes es demasiado alta, se producen errores de cuotas. Otro ejemplo de compensación es la cuota de la API de auditoría de correo electrónico para la tasa máxima de carga de mensajes general. La tasa de carga es de una solicitud a la API por segundo y por usuario, sin importar la cantidad de subprocesos que realicen solicitudes de carga.
Para todos los errores que se basan en el tiempo (máximo de N cosas por N segundos por subproceso), en especial, los errores del código de estado 503
, recomendamos que tu código detecte la excepción y, mediante un algoritmo de retirada exponencial, espera un pequeño retraso antes de reintentar la llamada con errores. Un ejemplo de la API de auditoría de correo electrónico para un subproceso es esperar 5 segundos y reintentar la llamada con errores. Si la solicitud se completa de forma correcta, repite este patrón para los otros subprocesos. Si la segunda solicitud no es exitosa, tu aplicación debería reducir la escala en la frecuencia hasta que una llamada sea exitosa.
Por ejemplo, aumente el retraso inicial de 5 segundos a 10 segundos y vuelva a intentar la llamada con errores. Además, establece un límite de reintentos. Por ejemplo, vuelve a intentar una solicitud entre 5 y 7 veces con diferentes tiempos de retraso antes de que tu aplicación le muestre un error al usuario.
En la siguiente tabla, se enumeran los límites para la API de auditoría de correo electrónico:
Categorías de límites de API | Límites |
---|---|
Archivos de buzón encriptados, creación | La creación de archivos de buzón encriptados puede tardar varios días en prepararse para el sistema, según el tamaño. |
Archivos de buzón encriptados encriptados, errores al borrarlo | Cuando borras un buzón encriptado y se producen errores, la solicitud recibe el estado MARKED_DELETE . Google vuelve a borrar automáticamente estos resúmenes y archivos de exportación en un plazo de 24 horas (con los archivos restantes posibles). Si el estado de MARKED_DELETE se muestra de manera constante, prueba una estrategia de retirada exponencial.
|
En la siguiente tabla, se muestran las cuotas para la API de auditoría de correo electrónico:
Categorías de cuota de API | Cuotas |
---|---|
Tokens de autenticación de ClientLogin | Válido durante 24 horas. El error es 401 token expired .
|
Formatos de fecha | Convierte todas las fechas al formato de tiempo universal coordinado (UTC) antes de usarlas con la API de auditoría de correo electrónico. Para obtener más información, consulta el convertidor de UTC. |
Archivos de buzón encriptados, resúmenes de EXPIRED y archivos de exportación encriptados
|
Google conserva los archivos de buzones de correo encriptados durante 3 semanas. Luego de ese plazo, se borrarán. Es responsabilidad del administrador del dominio descargar estos archivos de buzón en este período. |
Archivos de buzón encriptados, formato | Los archivos de buzón encriptados tienen el formato mbox. |
Archivos de buzón encriptados, solicitudes de creación máxima | La cantidad máxima de solicitudes de creación de exportaciones de buzones de correo por día es el total de 100 solicitudes de todos los administradores del dominio. |
Estado del archivo de buzón encriptado, paginación | Cuando se solicita el estado de todas las solicitudes de buzón, las respuestas pueden mostrar grandes cantidades de datos. La API de auditoría de correo electrónico agrupa esos datos en páginas que contienen cada
una cantidad máxima de 100 entradas y un URI en una etiqueta link rel='next' que apunta a la
siguiente página de resultados. Cuando desarrolles tu aplicación cliente, el código deberá administrar estos resultados adicionales.
|
Enviar un correo electrónico al monitor | La cantidad máxima de solicitudes de supervisión de correo electrónico por día es de 1,500. Este límite es para el dominio y, además, incluye todas las solicitudes que realizó cualquier administrador durante el día. |
Clave pública | La API de auditoría de correo electrónico solo admite una clave.
La clave pública usa software GNU Guard (GPG). Está en formato PGP y es una clave de encriptación RSA con codificación ASCII. Antes de subir la clave pública, debes convertirla en una string codificada en base64. El archivo de clave pública debe leerse con el conjunto de caracteres US-ASCII, (nombre de conjunto de caracteres preferido para IANA para ASCII). |
Buscando | Los parámetros searchQuery y includeDeleted son mutuamente excluyentes. Una búsqueda no es posible si includeDeleted="true" .
|