LinkedIn
Instagram
WhatsApp
Telegrama
Gmail
Outlook
Calendario de Google
Únase a la comunidad SlackLímites de la API de Gmail en 2026: Cuotas, Límites de Tasa, y Cómo Manejarlos
Referencia completa de cuotas de la API de Gmail que abarca límites por minuto, por usuario y diarios, costos unitarios por método, manejo de errores 429 y un patrón de retroceso exponencial listo para producción para usuarios autenticados.
async function withBackoff(fn, maxRetries = 5) { let delay = 1000; for (let i = 0; i < maxRetries; i++) { try { return await fn(); } catch (err) { if (err.code !== 429) throw err; const jitter = Math.random() * 500; await sleep(delay + jitter); delay *= 2; } }}Ámbito de la sesión del usuario autenticado
Unipile no mantiene un archivo paralelo de los datos del buzón de Gmail. Todo el acceso al correo electrónico es limitado a la sesión del usuario autenticado quien ha concedido explícitamente el consentimiento de OAuth. No se almacenan datos de forma independiente más allá de lo necesario para atender esa solicitud específica.
Intermediario técnico independiente
Unipile actúa como un intermediario técnico independiente, realizando llamadas a la API de Gmail en nombre de cada usuario autenticado de forma individual. Unipile no es un socio ni afiliado de Google. Las credenciales no se comparten entre usuarios. Cada token de OAuth pertenece exclusivamente al usuario que lo concedió.
La cadencia es una decisión del lado del cliente
Unipile retransmite los límites de velocidad y las restricciones de cuota de la API de Gmail tal como los define Google. La frecuencia y el volumen de las llamadas a la API realizadas en nombre de cada usuario es un decisión del lado del cliente. Unipile detecta errores de cuota y aplica una lógica de retroceso, pero la cadencia de llamada sigue bajo el control del desarrollador.
Límites de la API de Gmail de un vistazo
Antes de escribir una sola línea de lógica de reintento, debes tener una imagen clara de los tres ejes de cuotas que Google impone. La siguiente tabla es la referencia que marcarás: rendimiento por proyecto, límites por usuario y el techo diario que se reinicia a la medianoche, hora del Pacífico.
| Límite | Valor | Dimensión | Notas |
|---|---|---|---|
| Límite de tasa de la API de Gmail (unidades de cuota) | 1.200.000 / min | Por proyecto de GCP | Compartido entre todos los usuarios en el proyecto |
| Límite de tasa por usuario de la API de Gmail | 6,000 por minuto | Por buzón de usuario | El desencadenante más común para 429 en producción. |
| Cuota diaria | 80.000.000 / día | Por proyecto de GCP | Se reinicia a la medianoche hora del Pacífico |
| Límite de envío de Gmail (Gmail gratuito) | 500 correos electrónicos / día | Por dirección remitente | 2000 / día para Google Workspace |
| Solicitudes concurrentes por buzón | 50 | Por buzón | Límite oculto - se activa 429 independientemente de la cuota |
| Solicitudes por lotes por llamada | 100 solicitudes | Por lote de llamadas | Utilice procesamiento por lotes para reducir el consumo de unidades de cuota |
| Tamaño máximo de mensaje (adjuntos) | 25 MB | Por mensaje | Incluyendo encabezados y cuerpo codificado |
Fuente: Documentación de Google Developers, API de Gmail: límites de uso (última verificación: mayo de 2026). Los límites están sujetos a cambios; comprueba siempre la página de cuotas de tu consola de GCP para conocer los valores actuales de tu proyecto.
Las tres dimensiones de cuota
Los límites de uso de la API de Gmail funcionan en tres ejes independientes simultáneamente. Una solicitud puede ser bloqueada incluso si dos de los tres están bien. Comprender la separación entre los límites por proyecto, por usuario y diarios es el primer paso para escribir código resiliente para cualquier usuario autenticado.
Por proyecto (GCP)
1.200.000 unidades/minEsta es la techo agregado en todos los usuarios dentro de un único proyecto de GCP. Si tiene 500 usuarios autenticados realizando llamadas a la API de Gmail simultáneamente, todo su consumo de cuota se cuenta contra este único "cubo". Alcanzarlo activa límiteDeTarifasExcedido El equivalente diario es 80 millones de unidades, reiniciando a medianoche hora del Pacífico.
Por usuario (por buzón)
6,000 unidades/minEsta gorra se aplica de forma independiente a cada usuario autenticado. Incluso si tu proyecto tiene margen en las cuotas, un solo usuario que abuse de su propio buzón de correo con sondeos rápidos activará una Se excedió el límite de tasa del usuario 429. En aplicaciones multi-inquilino, este es el límite que se activa con mayor frecuencia: es por usuario, no compartido.
Cuota diaria
80.000.000 unidades/díaEl límite diario también es por proyecto. A diferencia de las ventanas por minuto que se recuperan automáticamente después de 60 segundos, al alcanzar el cuota diaria significa que no hay más acceso a la API hasta la medianoche del Pacífico. El error es límiteDiarioExcedido. Puedes solicitar un aumento de cuota a través de la consola de GCP; cubrimos eso en la sección multitenant.
Importante: Los límites de frecuencia de la API de Gmail anteriores se miden en "unidades de cuota", no en recuentos brutos de solicitudes. enviar mensajes la llamada cuesta 100 unidades, mientras que un mensajes.lista cuesta solo 5. Esto significa que su presupuesto de solicitudes prácticas varía significativamente según los métodos que llame. Consulte la tabla de costos unitarios en la siguiente sección. Tenga en cuenta también que Verificación de ámbito de OAuth los errores del flujo de consentimiento están completamente separados de estos errores de cuota en tiempo de ejecución.
Costo unitario de cuota por método
No todas las llamadas a la API de Gmail son iguales. Google cuenta el uso de cuotas en "unidades" abstractas, y cada método tiene un costo diferente. Conocer estos costos le permite calcular su capacidad real de solicitudes y optimizar los puntos finales que llama. El límite de tasa por usuario de la API de Gmail de 6,000 unidades/min se comporta de manera muy diferente según la combinación de sus llamadas.
| Método | Costo unitario | Solicitudes / min (por usuario) | Consejo de optimización |
|---|---|---|---|
| enviar mensajes | 100 | 60 envíos/min máx | Mayor costo - usar borrador + enviar solo cuando sea necesario |
| mensajes.insertar | 25 | 240/min max | Insertando en el buzón - menor que enviar |
| hilos.obtener | 10 | 600/min máx | Prefiere threads.get sobre multiple messages.get |
| mensajes.obtener | 5 | 1,200/min máx | Agrega fields=respuesta parcial para mantener el costo en 5 |
| mensajes.lista | 5 | 1,200/min máx | Usa history.list en lugar de los patrones de sincronización |
| hilos.lista | 5 | 1,200/min máx | Paginación con maxResults para reducir llamadas |
| usuarios.historial.listar | 2 | 3.000/min máx. | Mejor para sincronización incremental - menor costo de sondeo |
| etiquetas.lista | 1 | 6000/min máx | Almacenar el resultado en caché - las etiquetas rara vez cambian |
| mensajes.modificar | 5 | 1,200/min máx | Usa batchModify para actualizaciones masivas de etiquetas |
| mensajes.adjuntos.obtener | 5 | 1,200/min máx | Obtener archivos adjuntos solo cuando se necesiten explícitamente |
Consejo profesional: Puedes usar el campos= parámetro de consulta para respuestas parciales en cualquier método. Solicitar solo los campos que su aplicación necesita no reduce el costo unitario bruto, pero reduce drásticamente el tamaño de la carga útil de la respuesta y la latencia, lo cual es útil cuando se está cerca de los límites de la cuota de la API de Gmail. Pruebe sus consultas interactivamente usando el Gmail OAuth Playground antes de lanzar a producción.
El límite oculto de 50 solicitudes por buzón simultáneas
Existe un límite que la mayoría de los tutoriales de la API de Gmail nunca mencionan, sin embargo, es la causa de misteriosos errores 429 en aplicaciones multihilo o asíncronas: Gmail impone un máximo de 50 solicitudes concurrentes en vuelo por buzón. Este límite es completamente independiente de su presupuesto de unidades de cuota. Puede estar en 500 unidades de cuota de 6.000 disponibles y aun así recibir un 429 si tiene 51 solicitudes abiertas simultáneamente contra el buzón del mismo usuario autenticado.
¿Por qué esto sorprende a los desarrolladores?
Marcos asíncronos como Node.js Promise.all() o Python asyncio.gather() haz que sea increíblemente fácil lanzar más de 100 solicitudes concurrentes. Cuando procesas la sincronización de un buzón y se abren 200 mensajes simultáneamente para recuperarlos en nombre de un solo usuario autenticado, Gmail ve 200 conexiones TCP abiertas contra un buzón y limita inmediatamente. El panel de cuotas en GCP mostrará muchas unidades restantes; el límite de 50 concurrentes no se expone como una métrica de cuota.
Cuando se activa
El límite de 50 solicitudes simultáneas se activa durante las operaciones de sincronización masiva de buzones: al recuperar hilos grandes, descargar archivos adjuntos para muchos mensajes simultáneamente o paginar a través de un gran número de etiquetas mientras también se procesan los resultados de forma concurrente. Cualquier código que inicie más de 50 solicitudes en tránsito al mismo buzón alcanzará este límite.
Cómo arreglarlo
Utilisez un limiteur de concurrence (semaphore) limité par utilisateur authentifié. Dans Node.js, bibliothèques telles que límite-p funciona bien. En Python, una asyncio.Semaphore(40) con un margen seguro por debajo de 50 evita el estallido. Mantén tu concurrencia por usuario en 40 o menos por margen de seguridad.
// p-limit mantiene la concurrencia por usuario por debajo de 40import límite de p from 'límite-p';// Una instancia de limitador por usuario autenticado (con clave por userId)const Límites de usuario = new Mapa();función obtenerLimitador(userId) { si !limitadoresDeUsuario.ha)) { LimitadoresDeUsuario.conjunto(idUsuario, límite de p(40)); } return LimitadoresDeUsuario.consiga(userId);}// Envuelve cada llamada a la API de Gmail con el limitador del usuarioasync function recuperarMensaje(gmail, userId, messageId) { const límite = obtenerLimitador(userId); return limit(() => gmail.users.messages.consiga({ userId: yo, id: messageId, campos: 'id,threadId,payload.headers,snippet' }));}Interpretación de los errores: 429 frente a 403
La API de Gmail devuelve dos códigos de estado HTTP diferentes para problemas de cuota y acceso: 429 (Demasiadas solicitudes) y 403 (Prohibido). Dentro de esos dos códigos hay cuatro motivos de error distintos, cada uno con una causa raíz diferente y una resolución diferente. Confundirlos desperdicia tiempo de depuración. Nota: Errores del flujo de OAuth como concesión_inválida son errores de token de actualización - están completamente separadas de estos límites de tasa de la API de Gmail en tiempo de ejecución.
| Código HTTP | Razón del error | Causa | Arregla |
|---|---|---|---|
| 429 | límiteDeTarifasExcedido | Se superó la cuota de 1.2M de unidades por minuto a nivel de proyecto de GCP. Todos los usuarios autenticados en el proyecto alcanzaron colectivamente el límite. | Retroceso exponencial + jitter. Espera y reintenta. A largo plazo: fragmentar en múltiples proyectos de GCP o solicitar un aumento de cuota. |
| 429 | Se excedió el límite de tasa del usuario | Un solo usuario autenticado excedió 6.000 unidades de cuota/min, O excedió 50 solicitudes simultáneas a su buzón. El 429 de producción más común. | Cola por usuario con limitador de concurrencia. Aplicar el patrón semáforo (máximo 40 concurrentes). Añadir retroceso exponencial en reintentos 429. |
| 403 | límiteDiarioExcedido | El proyecto de GCP consumió las 80 millones de unidades de cuota diarias antes de la medianoche, hora del Pacífico. No se puede reintentar hasta el restablecimiento. Esto es un bloqueo total. | Espera al reinicio de medianoche del Pacífico o solicitar un aumento de cuota a través de la consola de GCP. Implemente un presupuesto de cuota diario por usuario en su aplicación. |
| 403 | Se ha superado el límite | Se excedió una sub-cuota específica. También puede indicar que se alcanzó la cuota de envío de Gmail (500 correos electrónicos/día gratis, 2.000 para Workspace) para una dirección de remitente específica. | Verificar qué cuota. Para enviar cuota: cambia la dirección de envío o espera 24h. Para otras subcuotas: identifica la métrica específica en el panel de cuotas de GCP. |
Se ha alcanzado el límite máximo a nivel de proyecto: 1,2 millones de unidades de cuota por minuto para todos los usuarios.
Corregir: Retroceso exponencial con fluctuación. A largo plazo: múltiples proyectos de GCP o solicitud de aumento de cuota.
Un solo usuario excedió 6,000 unidades/min O 50 solicitudes concurrentes. El 429 más común.
Corregir: Cola por usuario + semáforo (máximo 40 concurrentes). Añadir reintento con retroceso.
El proyecto consumió las 80 millones de unidades de cuota diaria. Parada total hasta la medianoche hora del Pacífico.
Corregir: Espera a que se restablezca la cuota o solicita un aumento de cuota a través de la consola de GCP.
Cuota secundaria o cuota de envío de Gmail (500/día gratis, 2000 Workspace) alcanzada para el remitente.
Corregir: Consulta el panel de control de GCP para ver la subcuota específica. Para el envío: cambia la dirección o espera 24 horas.
concesión_inválida, acceso_denegadoy cliente_inválido provienen de la capa de intercambio de tokens OAuth, no de la aplicación de cuotas de la API de Gmail. Se cubren por separado en Guía de errores de Google OAuth. Si ves un 401 No autorizado, eso también es un problema de autenticación, revisa tu Verificación de la aplicación OAuth estado y si el El token de actualización ha expirado. Manejo listo para producción: retroceso exponencial + aleatoriedad
El retroceso exponencial es la única respuesta correcta a un 429 de la API de Gmail. Reintentar inmediatamente empeora el problema: apilas más solicitudes en una ventana de cuota que ya está limitada. Agregar un jitter aleatorio evita el problema de la "manada de truenos" donde todos los clientes de una flota reintentan exactamente en el mismo momento. A continuación se presentan implementaciones completas y probadas en producción en Node.js y Python.
Retraso inicial
Comenzar con 1.000 ms en el primer reintento. Nunca reintentar inmediatamente después de un 429.
Multiplicador exponencial
Retraso doble en cada intento: 1 s, 2 s, 4 s, 8 s, 16 s. Límite máximo de 32-64 segundos.
Jitter aleatorio
Agregue jitter aleatorio de 0-500 ms para prevenir reintentos sincronizados entre trabajadores concurrentes.
// gmail-backoff.js - production-ready exponential backoff + jitter// Handles rateLimitExceeded and userRateLimitExceeded (gmail api rate limits)const sleep = (ms) => new Promise(r => setTimeout(r, ms));async function withGmailBackoff(fn, { maxRetries = 5, initialDelay = 1000, maxDelay = 32000, jitter = 500} = {}) { let delay = initialDelay; for (let attempt = 0; attempt < maxRetries; attempt++) { try { return await fn(); } catch (err) { const code = err?.code || err?.response?.status; const reason = err?.errors?.[0]?.reason || ''; // Only retry on quota errors - not on 403 dailyLimitExceeded const isRetryable = code === 429 || reason === 'rateLimitExceeded' || reason === 'userRateLimitExceeded'; if (!isRetryable || attempt === maxRetries - 1) throw err; const wait = Math.min(delay + Math.random() * jitter, maxDelay); await sleep(wait); delay *= 2; } }}// Usage: on behalf of each authenticated userconst message = await withGmailBackoff(() => gmail.users.messages.get({ userId: 'me', id: messageId }));# gmail_backoff.py - Retraso exponencial + fluctuación para los límites de frecuencia de la API de Gmailimport asíncrono, aleatoriofrom googleapiclient.errores import Error de conexión HTTPasync def con_espera_de_gmail( fn, reintentos_max5, retraso_inicial=1.0, retraso_max32.0, temblor=0.5): "Envuelve cualquier llamada a la API de Gmail con reintentos exponenciales y aleatoriedad. Maneja los límites de tasa de la API de Gmail: rateLimitExceeded y userRateLimitExceeded. """ retraso = retraso_inicial para intento en range(reintentos_max): intentar: return fn() La función # es una llamada de cliente de Gmail síncrona excepto Error de conexión HTTP como e: estado = e.resp.status razón = e.detalles_del_error[0].consiga('razón', '') si e.detalles_del_error si no '' #: reintentar en 429; NO reintentar en caso de dailyLimitExceeded reintentable = estado == 429 o razón en ( 'límite de velocidad excedido', 'elLímiteDeTasaDelUsuarioExcedido' ) si no reintentable o intento == max_reintentos - 1: elevar espera = mínimo(retraso + aleatorio.uniforme(0, jitter), max_delay) await asíncrono.dormirEspera retraso *= 2Estrategias para mantenerse por debajo del límite
Backoff se encarga de la situación de emergencia. Estas estrategias proactivas evitan, desde el principio, que se alcancen los límites de cuota de la API de Gmail. Se enumeran de mayor a menor impacto en el consumo de cuota. La combinación de dos o tres de ellas puede reducir el gasto unitario en un 80% en cargas de trabajo típicas con un uso intensivo de lectura.
Cola por usuario autenticado
Mantener una cola de solicitudes separada por usuario autenticado. Nunca se mezclen solicitudes de diferentes usuarios en un grupo compartido. Esto aísla la exposición de los límites de tasa por usuario y permite una cola justa: si un usuario activa un 429, solo su cola se pausa; los demás continúan a toda velocidad. Use Redis o una cola en memoria con un cubo de tokens por usuario.
Usa history.list en lugar de messages.list para sincronizar
Sondeo mensajes.lista en un temporizador es el error más común en los límites de uso de la API de Gmail. usuarios.historial.listar solo costos 2 unidades (frente a 5 en el caso de messages.list) y devuelve únicamente el delta desde el último punto de sincronización. En aplicaciones con un uso intensivo de lectura que sincronizan buzones de correo de gran tamaño, esta opción por sí sola puede reducir el consumo de cuota en un 60%. Almacena el historialId De cada respuesta mientras tu cursor. Asóciate con las notificaciones push de Gmail (Pub/Sub) para una sincronización casi en tiempo real.
Llamadas API por lotes
La API de Gmail admite solicitudes por lotes: combine hasta 100 solicitudes individuales en una sola llamada HTTP. Cada sub-petición sigue contando su coste unitario normal, pero se reduce la sobrecarga de TCP y las "ranuras" del límite de tasa consumidas. Esto es especialmente eficaz para mensajes.obtener operaciones donde necesitas recuperar muchos mensajes de un delta de sincronización. Consulta el Guía de lotes de Gmail para detalles de implementación.
Usar respuestas parciales (fields=)
Todos los métodos de la API de Gmail admiten el campos= parámetro para solicitar solo las propiedades que necesites. Aunque esto no reduce el coste unitario de la solicitud, reduce el volumen de datos de la respuesta entre un 60 % y un 90 % y mejora la latencia. Para un mensajes.obtener regresando solamente id,threadId,payload.headers,fragmento, la carga útil se reduce de más de 40 KB a menos de 2 KB. Menos red = iteración más rápida = más margen antes de alcanzar el límite de la cuota diaria de la API de Gmail.
Push vs. Poll: El modelo de sincronización adecuado
5 unidades por sondeo + N x 5 unidades para obtener cada nuevo mensaje. Para 100 usuarios x intervalo de 30 s = 1 millón de unidades/hora solo en sobrecarga de sondeo.
2 unidades por consulta; solo devuelve los cambios desde la última sincronización. 60% es más económico que consultar «messages.list» para obtener el mismo resultado.
Costo de cuota cero para la entrega. Google envía una notificación cuando cambia un buzón: recuperas solo la diferencia. Requiere un punto final de webhook público. Ideal para aplicaciones casi en tiempo real.
Escalabilidad multi-inquilino y solicitud de aumento de cuota
Una vez que va más allá de un puñado de cuentas vinculadas, las cuotas de la API de Gmail se convierten en una preocupación arquitectónica. Esta sección cubre la fragmentación de proyectos de GCP para implementaciones a gran escala y el proceso paso a paso para solicitar un aumento de cuota de la API de Gmail a Google.
Fragmentación de proyectos de GCP
El límite de 1,2M de unidades de cuota por minuto es por proyecto de GCP. Si tienes 1.000 usuarios autenticados sincronizando activamente, puedes dividirlos entre dos proyectos de GCP para duplicar tu capacidad efectiva a nivel de proyecto. Cada proyecto necesita sus propias credenciales de cliente OAuth y pantalla de consentimiento. Los usuarios vinculados al proyecto A no pueden usar la cuota del proyecto B. Esto es particularmente útil para escenarios de sincronización de correo electrónico de alto volumen donde el límite diario de la cuota de la API de Gmail es una preocupación. Monitorizar el uso de su cuota en la consola de GCP para saber cuándo se necesita la fragmentación.
Solicitar un aumento de cuota
Google otorga aumentos de cuota previa solicitud, pero toman tiempo (típicamente 3-5 días hábiles para la revisión inicial, hasta 2 semanas para aumentos grandes). Envía a través de la Consola de GCP: APIs y servicios > API de Gmail > Cuotas > "Solicitar mayor cuota". Google requiere una justificación detallada. Elementos clave a incluir: usuarios activos diarios estimados, solicitudes promedio por usuario por día, desglose por métodoenviar mensajes vs mensajes.lista etc.), y el caso de uso de producción. Las solicitudes vagas son denegadas. Proporcionar números concretos de su telemetría de staging.
Monitorizar y presupuestar la cuota diaria
Implementa el seguimiento del presupuesto de cuotas por usuario autenticado en tu propia capa de datos. Rastrea unidades de cuota utilizadas para cada usuario diariamente. Cuando un usuario se acerque a los 70-80% de su presupuesto diario por usuario, cambie de la sincronización activa al modo «solo push» para ese usuario durante el resto del día. Esto evita que un usuario con un volumen elevado agote de forma desproporcionada la cuota diaria a nivel de proyecto. La cadencia con la que se asigna la cuota por usuario es una decisión del lado del cliente en términos de diseño de su aplicación.
Qué incluir en su solicitud de aumento de cuota
Uso actual de referencia: "Actualmente utilizamos X millones de unidades/día entre Y usuarios activos."
Proyección de crecimiento: "En 6 meses esperamos Z usuarios, lo que requerirá aproximadamente W millones de unidades/día."
Caso de uso: "Nuestro producto lee Gmail para potenciar [sincronización de CRM / bandeja de entrada de ATS / análisis de correo electrónico]. Los usuarios se autentican individualmente a través de OAuth."
Desglose del método: "Métodos principales: messages.list (40%), messages.get (35%), history.list (20%), messages.send (5%)."
Cómo Unipile gestiona el estrangulamiento de Gmail en nombre del usuario autenticado
La construcción de toda la infraestructura de limitación descrita en esta guía (colas por usuario, semáforos, retroceso exponencial, presupuestos de cuota diaria, gestión de proyectos de GCP) lleva semanas y requiere mantenimiento continuo. Unipile se encarga de todo esto como intermediario técnico independiente, para que su equipo se centre en la lógica del producto, no en la fontanería de las cuotas. El acceso a la API de Gmail a través de Unipile no está afiliado, respaldado ni patrocinado por Google.
Retroceso exponencial administrado + jitter
Cada llamada a la API de Gmail realizada en nombre de cada usuario autenticado pasa por la capa de retroceso de Unipile. Los errores 429 son transparentes para tu código: Unipile reintenta automáticamente con retroceso exponencial completo y jitter, mostrando solo el éxito final o un error limpio después de los reintentos máximos.
Aislamiento de cola por usuario
Unipile mantiene un estricto aislamiento por usuario. Un usuario autenticado con límites de velocidad nunca impacta el rendimiento de otro usuario. Cada cuenta vinculada tiene su propia cola con límites de concurrencia individuales, lo que garantiza una asignación justa de recursos en toda su base de usuarios.
Modelo unificado: Gmail + Outlook + IMAP
La misma lógica de limitación se aplica de manera uniforme en Gmail, Outlook (Microsoft 365 y Exchange Online), y IMAP. Tu aplicación utiliza una API estandarizada independientemente del proveedor de correo electrónico que el usuario autenticado tenga enlazado. No hay código específico del proveedor para los límites de velocidad que mantener.
Cumple con el RGPD, Alineado con SOC2
Los datos a los que se accede a través de Unipile son limitado a la sesión del usuario autenticado quién concedió el consentimiento de OAuth. Sin archivo paralelo, sin almacenamiento a largo plazo de datos del buzón más allá de los requisitos de la sesión. Alineación con GDPR y SOC2 integrada.
// Con Unipile: sin reintentos, sin semáforos, sin seguimiento de cuotasUnipile maneja todos los límites de tarifas de la API de Gmail como un intermediario técnico independiente.import UnipileClient from '@unipile/node-sdk';const cliente = new UnipileClient({ apiKey: process.env.UNIPILE_API_KEY, baseUrl: 'https://api3.unipile.com:13613'});// List messages for an authenticated user's linked Gmail accountThrottling, backoff y aislamiento por usuario manejados en el lado del servidor por Unipileasync function obtenerCorreosRecientes(accountId) { const mensajes = await client.messaging.listMessages({ account_id: account_id, cuenta vinculada del usuario autenticado límite: 25 }); return mensajes;}// Funciona idénticamente para cuentas vinculadas de Gmail, Outlook e IMAP// Mismo código, sin manejo de límites de frecuencia específicos del proveedorLímites de tasa de la API de Gmail - Preguntas frecuentes
Respuestas a las preguntas más comunes sobre los límites de frecuencia de la API de Gmail, las unidades de cuota, los errores 429 y la escalada de su integración.
La API de Gmail impone límites en tres dimensiones simultáneamente. A nivel de proyecto: 1.200.000 unidades de cuota por minuto compartido entre todos los usuarios, y 80.000.000 unidades de cuota por día. A nivel de usuario: 6.000 unidades de cuota por minuto por buzón. También hay un límite oculto de 50 solicitudes concurrentes por buzón que puede generar un 429 incluso cuando estás muy por debajo del límite de unidades de cuota. Cada método tiene un costo de unidades diferente. enviar mensajes cuesta 100 unidades mientras mensajes.lista cuesta solo 5.
Implementar retroceso exponencial con jittercomenzar en 1000ms en el primer reintento, duplicar cada intento, agregar un jitter aleatorio de 0-500ms, limitar a 32000ms. Nunca reintentar inmediatamente. Agregar un limitador de concurrencia con alcance por usuario autenticado, manteniendo las solicitudes en curso por debajo de 40 por buzón. Usa un cola por usuario para que un usuario limitado no afecte a otros. A largo plazo, cambiar el sondeo desde mensajes.lista (5 unidades) a historial.lista (2 unidades) y considere las notificaciones push de Gmail para eliminar por completo el sondeo.
La API de Gmail la cuota diaria es de 80.000.000 unidades de cuota por proyecto de GCP, reiniciándose a medianoche hora del Pacífico. Este límite devuelve un 403 Límite diario excedido error - a diferencia de los errores 429 por minuto, este no se puede reintentar hasta el reinicio diario. Para aumentarlo: Consola de GCP > APIs y servicios > API de Gmail > Cuotas > Solicitar cuota más alta. Incluya el uso actual, las proyecciones de crecimiento y su caso de uso. La aprobación suele tardar de 3 a 5 días hábiles.
El Gmail el límite de envío es de 500 correos electrónicos por día para cuentas gratuitas de Gmail y 2.000 correos electrónicos al día para cuentas de Google Workspace. Este límite es por dirección del remitente y está separado del presupuesto de unidades de cuota de la API. Cada enviar mensajes la llamada también cuesta 100 unidades de cuota, por lo que con un límite de 6,000 unidades/min por usuario, puedes enviar como máximo 60 correos electrónicos por minuto antes de alcanzar el límite de tasa de la API de Gmail por usuario, pero el límite diario de 500/2,000 se alcanzará probablemente primero para casos de uso típicos.
límiteDeTarifasExcedido significa que todo el proyecto de GCP superó las 1.200.000 unidades de cuota por minuto, todos los usuarios autenticados juntos. Se excedió el límite de tasa del usuario significa que un solo usuario excedió las 6.000 unidades de cuota por minuto o envió más de 50 solicitudes concurrentes a su buzón. En aplicaciones multitenant de producción, Se excedió el límite de tasa del usuario es mucho más común porque los usuarios individuales pueden alcanzar sus límites de forma independiente, independientemente del margen general del proyecto. Ambos devuelven HTTP 429 y ambos responden al retroceso exponencial.
Navegar a Consola de GCP > APIs y Servicios > Gmail API > Cuotas y haz clic en "Solicitar mayor cuota". Tu solicitud debe incluir una justificación concreta: uso diario de referencia actual, proyección de crecimiento de usuarios a 6 meses, descripción de cómo los usuarios se autentican individualmente a través de OAuth y un desglose de los métodos de API por proporción. Las solicitudes vagas son denegadas. Asegúrate también de que tu aplicación sea OAuth verificado - las aplicaciones no verificadas están limitadas a 100 usuarios de prueba independientemente de la cuota. La revisión generalmente toma de 3 a 5 días hábiles para la respuesta inicial.
enviar mensajes costos 100 unidades de cuota por llamada: el método más caro de la API de Gmail. Con el límite por usuario de 6,000 unidades/min, puedes enviar como máximo 60 correos electrónicos por minuto por usuario autenticado. A modo de comparación: mensajes.obtener cuesta 5 unidades (1.200 llamadas/min), historial.lista cuesta 2 unidades (3,000 llamadas/min), y etiquetas.lista cuesta 1 unidad (6000 llamadas/min). Para contactos de alto volumen, considere si su caso de uso realmente requiere realizar llamadas enviar mensajes o si es más eficiente crear borradores y enviarlos en lotes.
Unipile solo accede a los datos solicitados explícitamente por su aplicación., limitado a la sesión del usuario autenticado quien ha otorgado el consentimiento OAuth. No existe un archivo paralelo, ni un almacenamiento independiente a largo plazo de los datos del buzón de correo más allá de lo necesario para atender la solicitud de API actual. Los datos de cada usuario autenticado están aislados: Unipile actúa como un intermediario técnico independiente en nombre de ese usuario específico únicamente.
la frecuencia y el volumen de las llamadas a la API realizadas en nombre de cada usuario autenticado es una decisión del lado del cliente. Unipile gestiona la infraestructura de retroceso y colas, pero tu aplicación determina con qué frecuencia solicitar datos. Unipile expone los errores de cuota de forma transparente y aplica lógica de reintento, pero la cadencia general de llamadas, incluyendo cuántos usuarios se sincronizan simultáneamente y con qué frecuencia, permanece bajo tu control como desarrollador que trabaja sobre Unipile.
No. Unipile es no afiliado con, avalado por, ni patrocinado por Google. Unipile es un intermediario técnico independiente que realiza llamadas a la API de Gmail en nombre de usuarios autenticados que han otorgado consentimiento OAuth individualmente a través de sus propias cuentas de Google. Gmail es una marca comercial de Google LLC. Todas las cuotas, límites de frecuencia y políticas de la API de Gmail están definidos por Google y sujetos a cambios independientemente de Unipile.
¿Preguntas sobre los límites de la API de Gmail y la integración de Unipile? Nuestro equipo está aquí para ayudarte.
La Guía Completa de la API de Email para Desarrolladores
Los límites de Gmail son una pieza del panorama de la API de correo electrónico. La guía principal cubre los patrones de integración de Gmail, Outlook e IMAP de principio a fin.
ES 
EN 
FR 
DE 
IT 
BR 
NL 
PL 
TR