LinkedIn
Instagram
WhatsApp
Telegrama
Calendario de Google
Únase a la comunidad SlackClave API de Gmail vs OAuthPor qué no puedes saltarte OAuth
¿Se puede usar una clave API de Google para acceder a Gmail? Respuesta corta: no. La API de Gmail accede a datos privados del usuario, lo que significa que cada solicitud requiere el consentimiento explícito del usuario a través de OAuth 2.0. Esta guía cubre el error exacto que verá si intenta usar una clave API, las 3 vías de autenticación reales disponibles hoy en día y cómo conectar un buzón de Gmail en 3 líneas de código usando una API de correo electrónico unificada.
Clave API de Gmail vs OAuth - el veredicto
// ----------------------------------------
// MAL: la clave de API NO funciona con Gmail
const res = await fetch(
https://gmail.googleapis.com/gmail/v1/
usuarios/yo/mensajes?clave=TU_CLAVE_API`
);
// Devuelve: 401 Se requiere inicio de sesión
// CORRECTO: token de acceso OAuth 2.0
const res = await fetch(
'https://gmail.googleapis.com/gmail/v1/users/me/messages',
{ headers: {
'Authorization': Portador ${token de acceso}`
} }
);
// O salta OAuth por completo - usa Unipile
const correos = await unipile.email.list(
{ idDeCuenta: 'id-cuenta-vinculada' }
);
¿Puedes usar una clave API con la API de Gmail?
Si ya has trabajado en Google Cloud antes, sabes que las claves API funcionan bien para Maps o Translate. Por lo tanto, es natural intentar el mismo enfoque con Gmail. No funcionará. Aquí te explicamos exactamente qué sucede y por qué, además del veredicto de dos frases antes de profundizar.
No. Las claves API de Google no pueden autenticarse contra la API de Gmail. Gmail accede a datos privados del usuario, lo que requiere el consentimiento explícito del usuario a través de OAuth 2.0. No hay ningún distintivo, encabezado ni solución alternativa que permita sustituir una clave de API por un token de acceso de OAuth en ningún punto final de Gmail. La API de Gmail devolverá un 401 Inicio de sesión requerido o Límite diario de 403 para uso no autenticado excedido error cada vez.
Clave API - Funciona solo para datos públicos
Una clave API identifica tu proyecto de Google Cloud para facturación y cuotas. Funciona con APIs públicas (Maps, Translate, datos públicos de YouTube) que no acceden a cuentas de usuario. Gmail nunca son datos públicos.
OAuth 2.0 - Requerido para la API de Gmail
OAuth 2.0 genera un token de acceso específico del usuario después de que el usuario otorga explícitamente su consentimiento. La API de Gmail lee ese token en cada solicitud para verificar tanto la identidad del usuario como el alcance del acceso aprobado. Sin un token de acceso válido, no hay respuesta.
Lo que realmente hace una clave de API en Google Cloud (y lo que no)
Las claves de API y los tokens de OAuth son dos mecanismos distintos que resuelven dos problemas diferentes. Confundirlos es uno de los errores más comunes al empezar con las API de Google. Aquí está la separación clara.
Google Maps Platform Geocodificación, Direcciones, Lugares (no se necesita cuenta de usuario)
API de Traducción de Google Cloud - Traducir texto, detectar idiomas
API de Datos de YouTube - Lectura de metadatos públicos de video, canales, listas de reproducción
Visión por Computadora / Procesamiento de Lenguaje Natural APIs de ML que procesan el contenido que cargas
Facturación + seguimiento de cuotas - Todo el uso de la clave API se mide contra tu proyecto
API de Gmail - Leer, enviar o administrar el buzón de cualquier usuario
API de Google Calendar - Leer o escribir eventos del calendario de cualquier usuario
API de Google Drive - Acceder, cargar o listar los archivos de un usuario
SDK de administración de Google Workspace - Cualquier operación con ámbito de administrador en un dominio
API de Personas (datos de usuario) Cualquier punto final que acceda a los contactos o al perfil de un usuario
La regla es simple: si una API accede a los datos de la cuenta de un usuario, Google exige que dicho usuario se autentique mediante OAuth 2.0. Las claves de API son credenciales de proyecto, no credenciales de usuario. La API de Gmail siempre se refiere a datos de usuario. Sin excepciones. Esta regla se aplica independientemente de si tu aplicación es pública o interna para tu empresa.
Por qué Gmail requiere OAuth 2.0
OAuth 2.0 no es una barrera burocrática que Google inventó para frenarte. Es la única forma técnicamente sólida de otorgar acceso con ámbito definido, revocable y auditable a datos privados de usuarios. Los tres requisitos principales de Gmail explican por qué una clave de API nunca puede sustituirlo.
El consentimiento del usuario es innegociable
Los datos de Gmail pertenecen al usuario, no a tu aplicación. OAuth 2.0 es el mecanismo por el cual un usuario dice explícitamente "sí, esta aplicación puede leer mi bandeja de entrada". Sin flujo de consentimiento, no hay acceso. Este es un requisito legal bajo el RGPD y una política de la plataforma de Google, no solo una restricción técnica.
Acceso limitado y revocable
Las tokens OAuth portan ámbitos, que son declaraciones precisas de lo que la aplicación puede y no puede hacer (solo lectura, enviar, acceso completo). Los usuarios pueden ver exactamente qué acceso concedieron y revocarlo en cualquier momento desde la configuración de su Cuenta de Google. Una clave API no otorga nada y no puede revocar nada a nivel de usuario.
La caducidad de los tokens protege a los usuarios
Los tokens de acceso de la API de Gmail caducan (generalmente en 1 hora). Esto significa que un token robado es inútil después de una corta ventana. Su aplicación debe actualizar silenciosamente los tokens utilizando un token de actualización, que a su vez puede ser revocado. Las claves API, por el contrario, son credenciales de proyecto de larga duración sin un mecanismo de revocación a nivel de usuario.
Google ha dejado de usar la autenticación de nombre de usuario/contraseña ("Autenticación básica") para Gmail en Septiembre 2024. Si tiene alguna integración heredada que utilice credenciales almacenadas directamente, ha dejado de funcionar. OAuth 2.0 es el único mecanismo de autenticación restante para la API de Gmail, tanto para integraciones nuevas como para las migradas. Ver el anuncio oficial de Google.
¿Necesitas gestionar OAuth para múltiples cuentas de Gmail en tu SaaS? Unipile gestiona la pantalla de consentimiento, el intercambio de tokens y la actualización silenciosa para cada cuenta vinculada, de modo que su código nunca toca un token.
Constrúyelo con UnipileLas 3 vías de autenticación reales para la API de Gmail
Una vez que aceptes que OAuth es inevitable, la pregunta es: ¿qué camino de OAuth se ajusta a tu caso de uso? Hay tres opciones arquitectónicamente distintas, cada una con diferentes compensaciones en cuanto a complejidad, alcance del usuario y sobrecarga de mantenimiento.
| Criterio | ID de cliente de OAuth 2.0 (3 pasos) | Cuenta de Servicio + DWD | API Unificada (Unipile) |
|---|---|---|---|
| ¿Se requiere consentimiento del usuario? | |||
| ¿Funciona con Gmail personal? | |||
| ¿SaaS multi-inquilino? | |||
| Gestión de tokens | Tu código almacena y actualiza tokens Mantenimiento elevado |
Clave JSON de cuenta de servicio Administrado por el administrador |
Unipile maneja todos los tokens Mantenimiento cero |
| Revisión de la pantalla de consentimiento de Google | |||
| ¿También es compatible con Outlook + IMAP? | |||
| Tiempo para leer el primer correo electrónico | 2-4 horas de configuración Aplicación OAuth + ámbitos + pantalla de consentimiento |
1-2 horas de configuración Administrador de espacio de trabajo requerido |
Menos de 15 minutos Clave de API + cuenta enlazada |
| Mejor para | Aplicaciones SaaS que conectan Gmail de usuarios externos | Herramientas internas del espacio de trabajo para tu organización | Cualquier caso de uso de API de correo electrónico: sin operaciones OAuth |
Ruta 1 - ID de cliente OAuth 2.0 (SaaS multitenant)
Si estás creando un producto SaaS donde tus clientes conectan sus propias cuentas de Gmail, el flujo de código de autorización OAuth 2.0 es el camino estándar. Este es el flujo de 3 patas: tu aplicación, Google y el usuario final. Requiere configurar un proyecto de Google Cloud y pasar por el proceso de verificación de la pantalla de consentimiento para alcances sensibles. Para una inmersión profunda en el Flujo de OAuth para APIs de correo electrónico en detalle, consulte nuestra guía dedicada.
Crear credenciales de OAuth 2.0 en la Google Cloud Console
Ve a APIs y servicios > Credenciales > Crear credenciales > ID de cliente OAuth. Elige "Aplicación web". Configura las URIs de redireccionamiento autorizadas para tu aplicación. Esto genera tu client_id y secreto_cliente.
Habilita la API de Gmail y declara tus ámbitos
Vaya a APIs y servicios > Pantalla de consentimiento de OAuth. Agregue los ámbitos de Gmail que necesita (por ejemplo,. gmail.lectura, gmail.enviarLos alcances sensibles y restringidos requieren verificación de Google, un proceso que lleva días o semanas.
Redirigir a los usuarios a la URL de autorización de Google
Cuando un usuario haga clic en "Conectar Gmail" en tu aplicación, redirígelo a Google con tu client_id, ámbitos y uri_redireccionamiento. Después de que aprueban, Google te devuelve un código de autorización a tu URI de redireccionamiento.
Intercambia el código por tokens y almacena el token de actualización
POST un código de autorización al endpoint de tokens de Google. Tú recibes un token_de_acceso (expira ~1h) y un token de actualización (de larga duración). Almacena el token de actualización de forma segura: es cómo obtienes nuevos tokens de acceso sin volver a pedirle al usuario que inicie sesión.
const { google } = require('googleapis');
const oauth2Cliente = new google.auth.OAuth2(
process.env.GMAIL_CLIENT_ID,
process.env.GMAIL_CLIENT_SECRET,
process.env.GMAIL_REDIRECT_URI
);
// Paso 1: Construir la URL de autorización
const urlDeAutenticación = oauth2Cliente.generarUrlDeAutenticación({
tipo_acceso: 'desconectado', // obtener token de actualización
ámbito: [
'https://www.googleapis.com/auth/gmail.readonly',
'https://www.googleapis.com/auth/gmail.send'
]
});
// Paso 2: Intercambiar código por tokens (en tu manejador de callback)
async function manejar callback(código) {
const { tokens } = await oauth2Cliente.obtenerToken(código);
oauth2Cliente.establecerCredenciales(tokens);
// Almacena tokens.refresh_token de forma segura en tu BD
return tokens;
}
// Paso 3: Usa el token de acceso para llamar a la API de Gmail
async function listaMensajes(accessToken) {
const gmail = google.gmail({ version: 'v1', auth: oauth2Client });
const res = await gmail.usuarios.mensajes.list({ userId: yo });
return res.data.mensajes;
}La gestión de los tokens de actualización a gran escala es el principal problema de #1 en Gmail OAuth autogestionado. Rotación de tokens, migraciones de bases de datos, fallos silenciosos en tokens caducados, todo esto se maneja automáticamente cuando utilizas un proveedor unificado de API de correo electrónico.
Crea tu integración de GmailRuta 2: Cuenta de servicio + delegación en todo el dominio (interno de Workspace)
Si su caso de uso es interno en una organización de Google Workspace (herramientas internas, automatización de recursos humanos o un panel de análisis de correo electrónico para toda la empresa), las cuentas de servicio con Delegación para todo el dominio (DWD) le permiten acceder a los buzones sin flujos de consentimiento por usuario. Un administrador de Workspace otorga la delegación una vez. La advertencia crítica: esta vía no funciona para direcciones de Gmail personales.
Las cuentas de servicio no pueden acceder a cuentas personales de Gmail (@gmail.com). DWD solo funciona dentro de un dominio de Google Workspace. Si sus usuarios se registran con direcciones de Gmail personales, debe usar la Ruta 1 (ID de cliente OAuth) o la Ruta 3 (API unificada). Intentar DWD en una cuenta personal devuelve un error 403.
Administrador de espacio de trabajo requerido DWD debe ser configurado por un administrador de Google Workspace en admin.google.com. No puedes hacer esto como desarrollador sin acceso de administrador.
Seguridad de claves JSON: La clave JSON de cuenta de servicio es una credencial de larga duración. Trátela como una clave privada: rótela regularmente y nunca la confirme en el control de código fuente.
Declaración de ámbito requerida: El administrador debe aprobar explícitamente cada alcance de Gmail durante la configuración de DWD. No puedes solicitar alcances en tiempo de ejecución. Ver Guía de DWD de Google.
from google.oauth2 import cuenta de servicio
from googleapiclient.discovery import construir
# Ruta a la clave JSON de tu cuenta de servicio
ARCHIVO_CUENTA_DE_SERVICIO = 'cuenta-de-servicio.json'
ÁMBITOS = [
'https://www.googleapis.com/auth/gmail.readonly'
]
#: Suplantar la identidad de un usuario en el dominio de Workspace
# (La delegación para todo el dominio debe ser habilitada por el administrador)
def obtener_servicio_gmail(correo_electronico_del_usuario):
acreditaciones = service_account.Credentials.desde_archivo_de_cuenta_de_servicio(
ARCHIVO_DE_CUENTA_DE_SERVICIO,
ámbitos=ÁMBITOS
)
# Esto es una delegación en todo el dominio: suplantar la identidad de un usuario
créditos delegados = créditos.con_asunto(correo_electronico_del_usuario)
return construir('Gmail', 'v1', credenciales=credenciales_delegadas)
#: Listado de mensajes de un usuario del espacio de trabajo
servicio = obtener_servicio_gmail('alice@yourcompany.com')
resultados = servicio.usuarios().mensajes().list(
ID de usuario=yo
).ejecutar()Ruta 3 - API de correo electrónico unificada (Omita el código repetitivo de OAuth)
Si tu objetivo es leer, enviar o sincronizar correos electrónicos en una aplicación SaaS de producción, y prefieres no dedicar ciclos de ingeniería a la gestión de infraestructura OAuth, una API de correo unificada como Unipile abstrae toda la capa de autenticación. Comprende cómo funciona la sincronización de correo electrónico internamente, o ir directamente al código. Este enfoque también te ofrece Gmail, Outlook e IMAP bajo una única API, sin necesidad de integraciones separadas para cada proveedor.
No se requiere configuración de Google Cloud
No hay ID de cliente OAuth, ni pantalla de consentimiento, ni revisión de ámbitos con Google. La propia aplicación OAuth verificada de Unipile se encarga de la autorización del usuario.
Rotación automática de tokens
Los tokens de acceso y los tokens de actualización son gestionados enteramente por Unipile. Tu base de datos nunca almacena un token de Google OAuth.
Funciona para Gmail personal + Outlook + IMAP
Una API, tres universos de proveedores. Cuando tú compara proveedores de API de sincronización de correo electrónico, el soporte entre proveedores es un diferenciador importante.
Entrega de webhook en mensajes nuevos
En lugar de consultar la API de Gmail, Unipile envía eventos de correo electrónico nuevos a tu endpoint de webhook en tiempo real, por cuenta enlazada.
// 3 líneas para leer un buzón de correo de Gmail a través de Unipile
// No configuración de OAuth, no gestión de tokens
const { UnipileClient } = require('unipile-node-sdk');
const client = new UnipileClient({
token: process.env.UNIPILE_API_KEY
});
// Listar correos electrónicos de una cuenta de Gmail vinculada
// accountId = el ID de cuenta enlazada de Unipile
const correos electrónicos = await cliente.email.listaMensajes({
account_id: 'id-cuenta-vinculada',
límite: 20
});
// Enviar un correo electrónico en nombre de la cuenta enlazada
await cliente.email.enviar({
account_id: 'id-cuenta-vinculada',
to: 'recipient@example.com',
tema: 'Hola desde Unipile',
body: 'Ningún token OAuth a la vista.'
});
Funciona idénticamente para Outlook e IMAP
// Solo cambia el account_idCrea tu integración de Gmail sin operaciones de OAuth
Empieza con la Guía completa de integración de la API de Gmail, luego despliegue con Unipile como su capa de autenticación y sincronización.
Errores comunes al intentar usar una clave de API con Gmail
Si has llegado a este artículo porque tu llamada a la API de Gmail está fallando, aquí tienes los dos errores que encontrarás y lo que significa cada uno, con el cuerpo de respuesta sin procesar para que los reconozcas al instante.
Enviaste una solicitud a la API de Gmail con una clave API (?clave=AIza...) o sin ninguna autorización. La API de Gmail requiere un token de acceso OAuth 2.0 válido en el Autorización: Bearer encabezado. Este es el primer error que verás al experimentar con una clave de API por primera vez.
Corregir: Implementa una de las 3 rutas de autenticación anteriores. La clave de API no es la solución: necesitas un token de acceso OAuth.
HTTP/1.1 401 No autorizado
Content-Type: application/json
{
"error": {
"code": 401,},
"mensaje": "La solicitud carece
de credencial
de autenticación
requerida. Se esperaba un
token de acceso OAuth 2,
una cookie de inicio de
sesión u otra credencial
de autenticación válida.
Consulte https://
developers.google.com/
identity/sign-in/web/...",
"estado": "NO AUTENTICADO",
"errores": [{
"mensaje": "Se requiere inicio de sesión",
"dominio": "googleapis.com",
"razón": "requerida",
"ubicación": "Authorization",
"tipoUbicación": "encabezado"
}]
}
}Tras solicitudes repetidas y no autenticadas (incluso con una clave API), el sistema de cuotas de Google bloquea posteriormente las llamadas no autenticadas desde tu IP o proyecto. Esto no es un límite de frecuencia para usuarios autenticados; significa específicamente que Tus solicitudes nunca fueron autenticadas y has agotado la pequeña cuota gratuita para llamadas anónimas.
Corregir: Lo mismo que arriba: su enfoque de clave API nunca funcionará. Use tokens de acceso OAuth 2.0. Este error desaparecerá una vez que sus solicitudes lleven un token de portador válido.
HTTP/1.1 403 Prohibido
Content-Type: application/json
{
"error": {
"code": 403,{
"code": 429,
"message": "Se ha superado el límite diario de uso no autenticado. El uso continuado requiere registro.",
"data": {
"message": "Se ha superado el límite diario de uso no autenticado. El uso continuado requiere registro.",
"status": "RESOURCE_EXHAUSTED",
"errors": [
{
"message": "Se ha superado el límite diario de uso no autenticado.",
"domain": "usageLimits",
"reason": "dailyLimitExceededUnreg"
}
]
}
}Alcances de la API de Gmail que realmente necesitarás
Una vez que aceptas que se requiere OAuth, la selección de alcance es la siguiente decisión crítica. Google clasifica los alcances de Gmail en tres niveles según la sensibilidad de los datos que exponen. Solicitar más de lo que necesitas activa un proceso de verificación más largo y, en algunos casos, una evaluación de seguridad completa por parte de Google.
Alcances sensibles (amarillo) requerir que Google revise tu pantalla de consentimiento OAuth y verifique la política de privacidad de tu aplicación. Ámbitos restringidos (rojo) requieren una evaluación de seguridad formal, una demostración en video y, a veces, una auditoría de seguridad de terceros. Planifique un mínimo de 2 a 6 semanas para la aprobación de un alcance restringido. Si utiliza Unipile como su capa de autenticación, este proceso de verificación recae en Unipile, no en su aplicación.
| Alcance | Nivel de acceso | Nivel | Caso práctico |
|---|---|---|---|
| gmail.lectura | Leer todos los mensajes, hilos, etiquetas, configuraciones | Sensible | Análisis de correo electrónico, herramientas de auditoría de bandeja de entrada, sincronización con CRM (solo lectura) |
| gmail.enviar | Enviar correo electrónico en nombre del usuario | Sensible | Correos electrónicos transaccionales del lado del usuario, seguimientos del CRM, herramientas de prospección |
| gmail.redactar | Crear, leer, actualizar, eliminar borradores; enviar mensajes | Sensible | Integraciones de composer de correo electrónico, gestión de borradores |
| gmail.modificar | Leer, enviar, modificar (etiquetas, archivar) - no eliminar | Restringido | Gestión completa de la bandeja de entrada, sincronización del CRM con escritura, flujos de trabajo de archivo |
| mail.google.com | Acceso completo: leer, escribir, eliminar, configurar | Restringido | Clientes de correo electrónico con todas las funciones, herramientas de copia de seguridad, migración de administradores |
| metadatos de gmail | Solo metadatos del mensaje (sin cuerpo) | No sensible | Análisis de volumen de correos electrónicos, patrones de remitente/destinatario (sin contenido) |
Crear una aplicación SaaS multi-inquilino que necesite gmail.modify o mail.google.com? La revisión de alcance restringido añade semanas a tu cronograma de lanzamiento. Con Unipile, te saltas por completo la revisión de la pantalla de consentimiento: la aplicación OAuth verificada de Unipile cubre los alcances que tu integración necesita.
Construir con UnipileÁrbol de decisión: ¿Qué método de autenticación para su caso de uso?
Responda tres preguntas y sabrá exactamente qué ruta de autenticación de la API de Gmail se aplica a su proyecto. No hay una respuesta universal: cada ruta resuelve un problema diferente. Para la guía completa Guía completa de integración de la API de Gmail, continúe hasta el centro de Gmail. Para el equivalente para Outlook / Microsoft 365, consulte nuestra guía de OAuth de Microsoft Graph.
Aplicación SaaS donde los clientes conectan su propio Gmail
¿Sus usuarios son externos (no sus empleados)?
Sí, son tus clientes con cuentas personales de Gmail o Google Workspace.
¿Necesitas admitir muchos dominios de Google diferentes?
Sí, multitenant. Cada usuario conecta su propia cuenta.
O Ruta 3 (API Unificada) para omitir la infraestructura de OAuth por completo.
Herramienta interna para tu propia organización de Google Workspace
¿Todos los usuarios pertenecen al mismo dominio de Workspace (sus empleados)?
Sí, solo cuentas de company.com. No se permiten usuarios externos de Gmail.
¿Tiene un administrador de Workspace que pueda configurar DWD?
Sí - acceso de administrador disponible en admin.google.com.
No flujos de consentimiento por usuario. El administrador delega una vez.
Aplicación SaaS que necesita Gmail + Outlook + IMAP bajo una sola API
¿Tienen sus usuarios una combinación de cuentas de Gmail, Outlook e IMAP?
Sí, no puedes predecir a qué proveedor se conectará cada usuario.
¿Quieres evitar ejecutar integraciones OAuth separadas por proveedor?
Sí, administrar Google OAuth + Microsoft OAuth + IMAP es demasiada complejidad.
Una clave API. Gmail, Outlook, IMAP. Sin operaciones OAuth.
Empieza a construir tu integración de Gmail hoy
Sin importar el camino que elijas, Unipile te ofrece una Resumen de la API unificada de correo electrónico para comprender la arquitectura antes de comprometerte con un enfoque. O salta directamente al panel y vincula tu primera cuenta en minutos.
Preguntas frecuentes
Las preguntas más comunes sobre la autenticación de la API de Gmail, claves API vs. tokens OAuth y cómo acceder a Gmail de forma programática sin gestionar tú mismo OAuth.
¿Puedo usar una clave API de Google para acceder a Gmail?
No. Las claves de la API de Google solo funcionan para APIs públicas no específicas del usuario, como Maps, Translate o YouTube Data (contenido público). La API de Gmail accede a datos del buzón de usuario privado, lo que requiere el consentimiento explícito del usuario a través de OAuth 2.0. Enviar una solicitud a la API de Gmail solo con una clave de API devuelve un 401 Inicio de sesión requerido o Límite diario de 403 para uso no autenticado excedido error - cada vez, sin excepción.
¿La API de Gmail requiere OAuth 2.0?
Sí, siempre. El acceso a la API de Gmail es acceso a datos del usuario, lo que significa que cada solicitud debe estar vinculada a un usuario autenticado que haya otorgado su consentimiento a través de un flujo de OAuth 2.0. No hay solución alternativa: ni clave de API, ni autenticación básica (obsoleto septiembre de 2024), sin encabezado mágico. Las tres rutas de autenticación admitidas son: ID de cliente OAuth 2.0 (multitenant), Cuenta de servicio con delegación en todo el dominio (solo Workspace) y una API de correo unificada como Unipile que se encarga de la capa OAuth por ti.
¿Cuál es la diferencia entre una clave de API y un ID de cliente de OAuth en Google Cloud?
En Clave de API identifica tu proyecto de Google Cloud a efectos de facturación y cuotas. Solo funciona para las APIs que sirven datos públicos (Maps, Translate, etc.). ID de cliente de OAuth se utiliza para iniciar un flujo de consentimiento donde un usuario real aprueba el acceso de su aplicación a su cuenta. El ID de cliente OAuth genera el token de acceso y el token de actualización que la API de Gmail realmente acepta. Estos son dos mecanismos completamente diferentes: uno identifica un proyecto, el otro autentica a un usuario.
¿Puede una cuenta de servicio leer Gmail sin el consentimiento del usuario?
Solo si Delegación en todo el dominio (DWD) es habilitado por un administrador de Google Workspace. Una cuenta de servicio por sí sola no puede acceder a ninguna bandeja de entrada de Gmail. Con DWD configurado, la cuenta de servicio puede suplantar a cualquier usuario de la organización y acceder a su buzón sin consentimiento interactivo. Limitación crítica: esto solo funciona para cuentas de Google Workspace (empresariales). No funciona para direcciones de Gmail personales (@gmail.com). Ver Documentación oficial de DWD de Google.
¿Por qué la API de Gmail devuelve "Se requiere inicio de sesión" con mi clave de API?
Porque La API de Gmail no acepta claves de API. El 401 Inicio de sesión requerido error significa que la solicitud carece de un token de acceso OAuth 2.0 válido en Authorization Encabezado. La API de Gmail espera: Autorización: Portador {access_token} - donde se obtuvo el token de acceso a través de un flujo OAuth 2.0 (código de autorización, JWT de cuenta de servicio o un token unificado de API). Simplemente adjuntando ?clave=TU_CLAVE_API A la API de Gmail no funcionará y devolverá 401 o 403.
¿Hay alguna forma de usar la API de Gmail sin tener que gestionar OAuth yo mismo?
Sí. Una API de correo electrónico unificada como Unipile maneja toda la capa de OAuth: la pantalla de consentimiento, el intercambio de tokens y la rotación silenciosa de tokens de actualización. Tu aplicación nunca almacena ni gestiona tokens de acceso o tokens de actualización. Llamas a la API de Unipile con tu propia clave de API, y Unipile se encarga de toda la comunicación OAuth con Google en tu nombre. Cuentas vinculadas. Esto elimina el proceso de aprobación de la pantalla de consentimiento de Google y la complejidad de la gestión de tokens de su código, y le brinda Gmail, Outlook e IMAP bajo una interfaz unificada.
ES 
EN 
FR 
DE 
IT 
BR 
NL 
PL 
TR