Límites y cuotas de uso
Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
Los límites y las cuotas protegen la infraestructura de Google de un proceso automatizado que usa la API de Data Transfer de forma inadecuada. El exceso de solicitudes de una API puede ser el resultado de un error tipográfico inofensivo o un sistema diseñado de forma 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 nivel
determinado para el estado general del sistema de Google Workspace. Garantiza que las acciones de un desarrollador no puedan afectar negativamente a toda la comunidad.
Fallas de solicitudes a la API
En el caso improbable de que falle la solicitud a la API, la aplicación recibirá una respuesta de código de estado HTTP. Un código de estado de 403
tiene información de error sobre entradas incorrectas, y un código de estado HTTP de 503
tiene información de error que indica qué cuotas de API se excedieron. Estas respuestas permiten que tu aplicación personalizada detecte estos errores y tome las medidas necesarias.
Completar solicitudes en un período fijo
Si debes completar tus solicitudes en un período fijo, envíalas en paralelo o usa varios subprocesos en tu aplicación de Java o C#. Por ejemplo, divide tus solicitudes por mes o por otro período. En el caso de los subprocesos, intenta comenzar con 10 subprocesos, uno por solicitud. La recomendación del subproceso tiene compensaciones y no es útil para todas las situaciones de API. Si la cantidad de solicitudes es demasiado alta, se producirán errores de cuota.
Errores basados en el tiempo
Para todos los errores basados en el tiempo (un máximo de N elementos por X segundos por subproceso), en especial los errores de código de estado 503
, recomendamos que el código detecte la excepción y, mediante el uso de un algoritmo de retirada exponencial, espere un pequeño retraso antes de reintentar la llamada con errores. Un ejemplo de la API de Data Transfer para un subproceso es esperar 5 segundos y reintentar la llamada con errores. Si la solicitud es exitosa, repite este patrón para los otros subprocesos. Si la segunda solicitud no es exitosa, la aplicación debe reducir la frecuencia de la solicitud hasta que la llamada sea exitosa. Por ejemplo, aumenta el retraso inicial de 5 segundos a 10 segundos y vuelve a intentar la llamada con errores. Además,
elige un límite de reintentos. Por ejemplo, reintentar una solicitud de 5 a 7 veces con tiempos de retraso diferentes antes de que tu aplicación le muestre un error al usuario.
Límites
Categorías de límites de API |
Límites |
Consultas por segundo (QPS) |
El límite de proyectos para desarrolladores es de 10 consultas por segundo (QPS) por cuenta. |
Cuotas
Categorías de cuota de la API |
Cuotas |
Cantidad máxima de solicitudes a la API por día |
La cantidad máxima de solicitudes a la API por día es de 500,000. |
Archivo, vencimiento de mensajes |
Los archivos del grupo no vencen. Los mensajes permanecerán en un archivo hasta que se borre el grupo. La política de retención de correo electrónico no afecta los mensajes del archivo de un grupo. |
Tamaño del mensaje de correo electrónico |
El tamaño máximo del mensaje de correo electrónico es de 25 MB. Este límite incluye los encabezados de metadatos, el cuerpo y los archivos adjuntos del mensaje. |
Otros tipos de límites
Otros tipos de límites |
Limitaciones y lineamientos |
Formatos de tipos de contenido |
Los mensajes de correo electrónico deben tener el formato de texto estándar RFC 822.
El formato de tipo de contenido de una solicitud para subir correos electrónicos migrados usa el encabezado Content-type: message/rfc822 .
|
Formato de datos en las respuestas de la API |
El formato de datos de la respuesta es JavaScript Object Notation (JSON).
|
Políticas de ubicación de datos |
La API de Data Transfer no admite políticas de ubicación de datos que requieran que los datos se almacenen en límites geográficos o políticos específicos por motivos contractuales. No uses la API de Data Transfer si se requiere la ubicación de los datos para tu cuenta. |
Inserciones de mensajes paralelos |
La API de Data Transfer admite solicitudes paralelas de inserciones de correo electrónico en diferentes
archivos de grupo. Sin embargo, la API de Data Transfer no admite inserciones de mensajes paralelas en el mismo archivo de grupo. Esta versión de la API tampoco admite solicitudes por lotes. |
Solicitudes no autorizadas |
La API de Data Transfer no acepta solicitudes no autorizadas. Una solicitud se considera no autorizada si no se proporciona un token de autorización.
|
Salvo que se indique lo contrario, el contenido de esta página está sujeto a la licencia Atribución 4.0 de Creative Commons, y los ejemplos de código están sujetos a la licencia Apache 2.0. Para obtener más información, consulta las políticas del sitio de Google Developers. Java es una marca registrada de Oracle o sus afiliados.
Última actualización: 2025-08-29 (UTC)
[null,null,["Última actualización: 2025-08-29 (UTC)"],[],[],null,["# Usage limits and quotas\n\nLimits and quotas protect the Google infrastructure from an automated process that uses the\nData Transfer API in an inappropriate way. Excessive requests from an API might result from a\nharmless typo, or might result from an inefficiently designed system that makes needless API\ncalls. Regardless of the cause, blocking traffic from a specific source when it reaches a certain\nlevel is necessary for the overall health of the Google Workspace system. It ensures that one\ndeveloper's actions can't negatively impact the larger community.\n\nAPI request failures\n--------------------\n\nIn the unlikely event that your API request fails, your application receives an HTTP status code\nresponse. A status code of `403` has error information about incorrect input, and an\nHTTP status code of `503` has error information indicating which API quotas have been\nexceeded. These responses let your custom application detect these errors and take appropriate\naction.\n\nComplete requests in a fixed time period\n----------------------------------------\n\nIf your requests need to be completed in a fixed period of time, send your requests in parallel\nor use multiple threads in your Java or C# application. For example, break your requests by month\nor another time period. In the case of threads, try starting with 10 threads, one thread per\nrequest. The thread recommendation has trade-offs and isn't useful for all API situations. If the\nnumber of requests gets too high, quota errors will occur.\n\nTime-based errors\n-----------------\n\nFor all errors that are time based (maximum of N things for X seconds per thread), especially the\n`503` status code errors, we recommend that your code catch the exception and by using\nan\n[exponential backoff](http://wikipedia.org/wiki/Truncated_binary_exponential_backoff)\nalgorithm, wait for a small delay before retrying the failed call. A Data Transfer API example\nfor one thread is to wait 5 seconds and retry the failed call. If the request is successful,\nrepeat this pattern for the other threads. If the second request is not successful, your\napplication should scale back on the frequency of the request until a call is successful. For\nexample, increase the initial 5 second delay to 10 seconds and retry your failed call again. Also,\ndecide on a retry limit. For example retry a request 5 to 7 times with different delay times\nbefore your application returns an error to the user.\n\nLimits\n------\n\n| API limit categories | Limits |\n|--------------------------|-------------------------------------------------------------------------|\n| Queries per second (QPS) | The developer project limit is 10 queries per second (QPS) per account. |\n\nQuotas\n------\n\n| API quota categories | Quotas |\n|---------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| Maximum API requests per day | The maximum API requests per day is 500,000. |\n| Archive, expiration of messages | Group archives don't expire. Messages remain in an archive until the group is deleted. The email retention policy doesn't affect messages in a group's archive. |\n| Mail message size | The maximum mail message size is 25MB. This limit includes the message's meta data headers, body, and any attachments. |\n\nOther types of limits\n---------------------\n\n| Other types of limits | Limitations and guidelines |\n|------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| Content type formats | An email message must be in the standard [RFC 822 text format](http://www.w3.org/Protocols/rfc822/). A request's content-type format for uploading migrated emails use the `Content-type: message/rfc822` header. |\n| Data format in API responses | The response's data format is Javascript Object Notation ([JSON](http://json.org/)). |\n| Data location policies | The Data Transfer API doesn't support data location policies requiring data be stored in specific geographic or political boundaries for contractual reasons. Don't use the Data Transfer API if data location is required for your account. |\n| Parallel message insertions | The Data Transfer API supports parallel requests for email insertions into different group archives. But the Data Transfer API doesn't support parallel message insertions into the same group archive. Nor are batch requests supported in this version of the API. |\n| Unauthorized requests | The Data Transfer API doesn't accept any unauthorized requests. A request is considered unauthorized if no authorization token is provided. |"]]