LinkedIn
Instagram
WhatsApp
Telegrama
Google Agenda
Participe da comunidade do SlackChave de API do Gmail vs OAuth: Por que você não pode pular o OAuth
Você pode usar uma chave de API do Google para acessar o Gmail? Resposta curta: não. A API do Gmail acessa dados privados do usuário, o que significa que cada solicitação precisa de consentimento explícito do usuário por meio do OAuth 2.0. Este guia cobre o erro exato que você verá se tentar usar uma chave de API, os 3 caminhos de autenticação reais disponíveis hoje e como conectar uma caixa de correio do Gmail em 3 linhas de código usando um API de e-mail unificada.
// Chave de API do Gmail vs OAuth - o veredito
// ----------------------------------------
// ERRADO: Chave da API NÃO funciona com o Gmail
const res = await fetch(
https://gmail.googleapis.com/gmail/v1/
usuários/me/mensagens?chave=SUA_CHAVE_API`
);
// Retorna: 401 Login Necessário
// CORRETO: Token de acesso OAuth 2.0
const res = await fetch(
'https://gmail.googleapis.com/gmail/v1/users/me/messages',
{ headers: {
'Authorization': Portador ${accessToken}`
} }
);
// OU pule o OAuth completamente - use Unipile
const correios = await unipilar.e-mail.list(
accountId: 'id-conta-vinculada' }
);
É possível usar uma chave de API com a API do Gmail?
Se você já desenvolveu no Google Cloud antes, sabe que as chaves de API funcionam bem para Maps ou Translate. Portanto, é natural tentar a mesma abordagem com o Gmail. Não vai funcionar. Veja exatamente o que acontece e por que - além do veredicto de duas frases antes de entrarmos em detalhes.
Não. Chaves de API do Google não podem autenticar na API do Gmail. O Gmail acessa dados privados do usuário, o que requer consentimento explícito do usuário via OAuth 2.0. Não existe uma flag, um cabeçalho ou uma solução alternativa que permita substituir uma chave de API por um token de acesso OAuth em qualquer endpoint do Gmail. A API do Gmail retornará um 401 Login Necessário ou 403 Limite Diário para Uso Não Autenticado Excedido erro toda hora.
Chave de API - Funciona apenas para dados públicos
Uma chave de API identifica seu projeto do Google Cloud para faturamento e cotas. Ela funciona com APIs públicas (Maps, Translate, dados públicos do YouTube) que não acessam contas de usuários. O Gmail nunca é um dado público.
OAuth 2.0 - Necessário para a API do Gmail
O OAuth 2.0 gera um token de acesso específico do usuário após o usuário conceder explicitamente consentimento. A API do Gmail lê esse token em cada solicitação para verificar a identidade do usuário e o escopo de acesso aprovado. Nenhum token de acesso válido = nenhuma resposta.
O que uma chave de API realmente faz (e não faz) no Google Cloud
Chaves de API e tokens OAuth são dois mecanismos distintos que resolvem dois problemas diferentes. Confundi-los é um dos erros mais comuns ao começar com as APIs do Google. Aqui está a separação clara.
Plataforma Google Maps - Geocodificação, Rotas, Lugares (sem necessidade de conta de usuário)
API de Tradução em Nuvem - Traduzindo texto, detectando idiomas
API de Dados do YouTube - Leitura de metadados de vídeos públicos, canais, playlists
Visão Computacional / Linguagem Natural - APIs de ML que processam o conteúdo que você carrega
Cobrança + Rastreamento de Cota - Todo uso de chave de API é medido em relação ao seu projeto
API do Gmail - Ler, enviar ou gerenciar a caixa de correio de qualquer usuário
API do Google Agenda - Ler ou escrever quaisquer eventos de calendário de um usuário
API do Google Drive - Acessar, fazer upload ou listar arquivos de um usuário
Google Workspace Admin SDK - Qualquer operação com escopo de administrador em um domínio
API de Pessoas (dados do usuário) Qualquer endpoint que toque nos contatos ou no perfil de um usuário
A regra é simples: Se uma API acessar os dados da conta de um usuário, o Google exige que esse usuário se autentique via OAuth 2.0. Chaves de API são credenciais de projeto, não credenciais de usuário. A API do Gmail sempre se refere a dados do usuário. Sem exceções. Essa regra se aplica independentemente de seu aplicativo ser público ou interno à sua empresa.
Por que o Gmail exige OAuth 2.0
OAuth 2.0 não é um obstáculo burocrático que o Google inventou para te atrasar. É a única maneira tecnicamente sólida de conceder acesso com escopo, revogável e auditável a dados privados do usuário. Os três requisitos principais do Gmail explicam por que uma chave de API nunca pode ser um substituto.
O consentimento do usuário é inegociável
Os dados do Gmail pertencem ao usuário, não ao seu aplicativo. OAuth 2.0 é o mecanismo pelo qual um usuário diz explicitamente "sim, este aplicativo pode ler minha caixa de entrada". Sem fluxo de consentimento = sem acesso. Este é um requisito legal sob o GDPR e uma política da plataforma Google, não apenas uma restrição técnica.
Acesso com escopo e revogável
Tokens OAuth carregam escopos - declarações precisas do que o aplicativo pode e não pode fazer (somente leitura, enviar, acesso total). Os usuários podem ver exatamente que acesso concederam e revogá-lo a qualquer momento nas configurações de sua Conta do Google. Uma chave de API não concede nada e não pode revogar nada no nível do usuário.
A expiração de tokens protege os usuários
Tokens de acesso da API do Gmail expiram (geralmente após 1 hora). Isso significa que um token roubado se torna inútil após uma curta janela de tempo. Seu aplicativo deve atualizar tokens silenciosamente usando um token de atualização - que, por si só, pode ser revogado. As chaves de API, em contraste, são credenciais de projeto de longa duração, sem mecanismo de revogação em nível de usuário.
O Google descontinuou a autenticação por nome de usuário/senha ("Autenticação Básica") para o Gmail em Setembro de 2024. Se você tiver alguma integração legada usando credenciais armazenadas diretamente, ela parou de funcionar. O OAuth 2.0 é o único mecanismo de autenticação restante para a API do Gmail - tanto para novas integrações quanto para as migradas. Veja o anúncio oficial do Google.
Precisa lidar com OAuth para múltiplas contas do Gmail no seu SaaS? Unipile gerencia a tela de consentimento, a troca de tokens e a atualização silenciosa para cada conta vinculada - assim o seu código nunca lida com um token.
Construa com UnipileOs 3 caminhos de autenticação reais para a API do Gmail
Uma vez que você aceita que o OAuth é inevitável, a questão se torna: qual caminho do OAuth se encaixa no seu caso de uso? Existem três opções arquiteturalmente distintas - cada uma com diferentes compromissos entre complexidade, escopo do usuário e sobrecarga de manutenção.
| Critério | ID do cliente OAuth 2.0 (3 etapas) | Conta de Serviço + DWD | API Unificada (Unipile) |
|---|---|---|---|
| Consentimento do usuário necessário? | |||
| Funciona com Gmail pessoal? | |||
| SaaS multi-inquilino? | |||
| Gerenciamento de tokens | Seu código armazena e atualiza tokens Alto custo de manutenção |
Chave JSON da conta de serviço Gerenciado pelo administrador |
Unipile lida com todos os tokens Manutenção zero |
| Revisão da tela de consentimento do Google? | |||
| Também suporta Outlook + IMAP? | |||
| Tempo para primeira leitura de e-mail | 2 a 4 horas para configurar Aplicativo OAuth + escopos + tela de consentimento |
1-2 horas de configuração Administrador do espaço de trabalho necessário |
Sob 15 minutos Chave de API + conta vinculada |
| Melhor para | Aplicativos SaaS conectando e-mails do Gmail de usuários externos | Ferramentas de espaço de trabalho internas para sua organização | Qualquer caso de uso de API de e-mail - sem operações OAuth |
Caminho 1 - ID do Cliente OAuth 2.0 (SaaS Multilocatário)
Se você está construindo um produto SaaS onde seus clientes conectam suas próprias contas do Gmail, o fluxo de código de autorização OAuth 2.0 é o caminho padrão. Este é o fluxo de 3 patas: seu aplicativo, o Google e o usuário final. Ele requer a configuração de um projeto no Google Cloud e a passagem pelo processo de verificação da tela de consentimento para escopos sensíveis. Para um mergulho profundo em Fluxo OAuth para APIs de E-mail em detalhe, veja nosso guia dedicado.
Crie credenciais do OAuth 2.0 no Google Cloud Console
Vá para APIs e Serviços > Credenciais > Criar Credenciais > ID do cliente OAuth. Escolha "Aplicativo da web". Configure os URIs de redirecionamento autorizados para seu aplicativo. Isso gera seu id_cliente e segredo_do_cliente.
Ativar a API do Gmail e declarar seus escopos
Acessar APIs e serviços > Tela de consentimento do OAuth. Adicionar os escopos do Gmail necessários (por exemplo,. gmail.somente leitura, gmail.enviarEscopos sensíveis e restritos exigem verificação pelo Google, um processo que leva dias ou semanas.
Redirecione os usuários para a URL de autorização do Google
Quando um usuário clicar em "Conectar Gmail" em seu aplicativo, redirecione-o para o Google com o seu id_cliente, escopos, e redirect_uri. Depois que eles aprovam, o Google envia de volta um código de autorização para a sua URI de redirecionamento.
Troque o código por tokens e armazene o token de atualização
POSTE o código de autorização para o endpoint de token do Google. Você recebe um token_de_acesso (expira ~1h) e um token_de_atualização (long-lived). Armazene o token de atualização de forma segura - é assim que você obtém novos tokens de acesso sem solicitar novamente ao usuário.
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
);
// Etapa 1: Construir a URL de autorização
const authUrl = oauth2Cliente.gerarUrlDeAutenticação({
tipo_acesso: 'offline', // obter token de atualização
escopo: [
'https://www.googleapis.com/auth/gmail.readonly',
'https://www.googleapis.com/auth/gmail.send'
]
});
// Etapa 2: Trocar código por tokens (no seu manipulador de callback)
async function handleCallback(código) {
const { tokens } = await oauth2Cliente.obterToken(código);
oauth2Cliente.definirCredenciais(tokens);
// Armazene tokens.refresh_token de forma segura no seu banco de dados
return tokens;
}
// Passo 3: Use o token de acesso para chamar a API do Gmail
async function listarMensagens(accessToken) {
const gmail = google.gmail({ versão: 'v1', auth: oauth2Client });
const res = await gmail.users.messages.list({ userId: "eu });
return res.data.mensagens;
}A gestão de tokens de atualização em grande escala é o principal desafio do #1 No Gmail OAuth auto-gerenciado. Rotação de tokens, migrações de banco de dados, falhas silenciosas em tokens expirados - tudo isso é tratado automaticamente quando você usa um provedor unificado de API de e-mail.
Crie sua integração com o GmailCaminho 2 - Conta de Serviço + Delegação em Toda a Rede (Interno do Workspace)
Se o seu caso de uso for interno a uma organização do Google Workspace - pense em ferramentas internas, automação de RH ou um painel de análise de e-mail para toda a empresa - contas de serviço com Delegação de Domínio Ampliado (DWD) permitem acessar caixas de correio sem fluxos de consentimento por usuário. Um administrador do Workspace concede a delegação uma vez. A ressalva crítica: este caminho não funciona para endereços de e-mail pessoais do Gmail.
Contas de serviço não podem acessar contas pessoais do Gmail (@gmail.com). O DWD só funciona dentro de um domínio do Google Workspace. Se seus usuários se cadastrarem com endereços pessoais do Gmail, você deverá usar o Caminho 1 (ID do cliente OAuth) ou o Caminho 3 (API unificada). Tentar usar o DWD em uma conta pessoal retorna um erro 403.
Administrador do espaço de trabalho necessário: O DWD deve ser configurado por um administrador do Google Workspace em admin.google.com. Você não pode fazer isso como desenvolvedor sem acesso de administrador.
Segurança de chaves JSON: A chave JSON da conta de serviço é uma credencial de longa duração. Trate-a como uma chave privada - alterne-a regularmente e nunca a inclua no controle de versão.
Declaração de escopo necessária: O administrador deve aprovar explicitamente cada escopo do Gmail durante a configuração do DWD. Você não pode solicitar escopos em tempo de execução. Veja Guia DWD do Google.
from google.oauth2 import conta de serviço
from googleapiclient.discovery import construir
#: Caminho para a chave JSON da sua conta de serviço
ARQUIVO_CONTA_DE_SERVICO = 'service-account.json'
ESCOPOS = [
'https://www.googleapis.com/auth/gmail.readonly'
]
# Suplantar a identidade de um usuário no domínio do Workspace
# (A delegação em todo o domínio deve ser ativada pelo administrador)
def obter_serviço_gmail(email_do_usuário):
credenciais = contas_de_serviço.Credenciais.from_service_account_file(
ARQUIVO_CONTA_DE_SERVIÇO,
escopos=ESCOPOS
)
# Esta é uma delegação em todo o domínio: assumir a identidade do usuário
creds_delegadas = creds.com_assunto(email_do_usuario)
return construir('gmail', 'v1', credenciais=creds_delegados)
# Listar mensagens de um usuário do Workspace
serviço = obter_serviço_gmail('alice@yourcompany.com')
resultados = serviço.usuários().mensagens().list(
userId="eu
).executar()Caminho 3 - API Unificada de E-mail (Pule o Código Repetitivo do OAuth)
Se o seu objetivo é ler, enviar ou sincronizar e-mails em um aplicativo SaaS de produção e você prefere não gastar ciclos de engenharia gerenciando infraestrutura OAuth, uma API de e-mail unificada como a Unipile abstrai toda a camada de autenticação. Entendi. como funciona a sincronização de e-mails por baixo dos panos, ou vá direto para o código. Essa abordagem também oferece o Gmail, Outlook e IMAP sob uma única API - sem integração separada para cada provedor.
Nenhuma configuração do Google Cloud necessária
Sem ID de cliente OAuth, sem tela de consentimento, sem revisão de escopo com o Google. O aplicativo OAuth próprio e verificado da Unipile lida com a autorização do usuário.
Rotação automática de token
Tokens de acesso e tokens de atualização são gerenciados inteiramente pela Unipile. Seu banco de dados nunca armazena um token OAuth do Google.
Funciona para Gmail pessoal + Outlook + IMAP
Uma API, três universos de provedores. Quando você compare provedores de API de sincronização de e-mail, o suporte entre provedores é um grande diferencial.
Entrega de Webhook em novas mensagens
Em vez de consultar a API do Gmail, o Unipile envia eventos de novos e-mails para seu endpoint de webhook em tempo real, por conta vinculada.
// 3 linhas para ler uma caixa de correio do Gmail via Unipile
// Nenhuma configuração OAuth, nenhum gerenciamento de token
const { UnipileClient } = require('unipile-node-sdk');
const client = new UnipileClient({
token: process.env.UNIPILE_API_KEY
});
// Listar emails de uma conta Gmail vinculada
// accountId = o ID da conta vinculada ao Unipile
const e-mails = await cliente.email.listarMensagens({
account_id: 'id-conta-vinculada',
limite: 20
});
// Enviar um e-mail em nome da conta vinculada
await cliente.email.enviar({
account_id: 'id-conta-vinculada',
to: 'recipient@example.com',
Assunto: 'Olá da Unipile',
body: 'Nenhum token OAuth à vista.'
});
// Funciona identicamente para Outlook e IMAP
// Apenas troque o account_idCrie sua integração com o Gmail sem operações OAuth
Comece com o Guia completo de integração com a API do Gmail, depois implante com o Unipile como sua camada de autenticação e sincronização.
Erros Comuns ao Tentar Usar uma Chave de API com o Gmail
Se você chegou a este artigo porque sua chamada à API do Gmail está falhando, aqui estão os dois erros que você encontrará e o que cada um deles significa, com o corpo da resposta bruta para que você possa reconhecê-los instantaneamente.
Você enviou uma solicitação para a API do Gmail com uma chave de API (?chave=AIza...ou sem autorização alguma. A API do Gmail exige um token de acesso OAuth 2.0 válido no Autorização: Bearer cabeçalho. Este é o primeiro erro que você verá ao experimentar uma chave de API pela primeira vez.
Correção: Implemente um dos 3 caminhos de autenticação acima. A chave de API não é a solução - você precisa de um token de acesso OAuth.
HTTP/1.1 401 Não Autorizado
Content-Type: application/json
"erro": {
"código": 401,
"message": "Solicitação está faltando credencial de autenticação
obrigatória. Espera-se um token de
acesso OAuth 2, cookie de login ou outra
credencial de autenticação válida. Ver
https://developers.google.com/identity/
sign-in/web/...",
"status": "UNAUTHENTICATED",
"errors": [{
"message": "Login Required",
"domain": "googleapis.com",
"reason": "required",
"location": "Authorization",
"locationType": "header"
}]
}
}Após requisições repetidas não autenticadas (mesmo com chave de API), o sistema de cotas do Google bloqueia chamadas não autenticadas adicionais do seu IP ou projeto. Este não é um limite de taxa para usuários autenticados - significa especificamente suas solicitações nunca foram autenticadas e você esgotou a pequena cota gratuita para chamadas anônimas.
Correção: O mesmo que acima - sua abordagem de chave de API nunca funcionará. Use tokens de acesso OAuth 2.0. Esse erro desaparecerá assim que suas requisições carregarem um token Bearer válido.
HTTP/1.1 403 Proibido
Content-Type: application/json
"erro": {
"código": 403,},
"message": "Limite diário para
uso não autenticado excedido.
O uso contínuo requer
cadastro.",
"status": "RESOURCE_EXHAUSTED",
"errors": [{
"message": "Limite diário para
uso não autenticado
excedido.",
"domain": "usageLimits",
"reason":
"dailyLimitExceededUnreg"
}]
}
}Escopos da API do Gmail que você realmente precisará
Uma vez que você aceita que o OAuth é necessário, a seleção de escopos é a próxima decisão crítica. O Google classifica os escopos do Gmail em três níveis com base na sensibilidade dos dados que eles expõem. Solicitar mais do que você precisa desencadeia um processo de verificação mais longo e, em alguns casos, uma avaliação completa de segurança pelo Google.
Escopos sensíveis (amarelo) exigir que o Google revise a tela de consentimento do OAuth e verifique a política de privacidade do seu aplicativo. Escopos restritos (vermelho) requer uma avaliação de segurança formal, uma demonstração em vídeo e, às vezes, uma auditoria de segurança de terceiros. Planeje um mínimo de 2 a 6 semanas para a aprovação de escopo restrito. Se você usar o Unipile como camada de autenticação, este processo de verificação recairá sobre o Unipile - não sobre seu aplicativo.
| Escopo | Nível de acesso | Nível | Caso de uso |
|---|---|---|---|
| gmail.somente leitura | Ler todas as mensagens, tópicos, marcadores, configurações | Sensível | Análise de e-mail, ferramentas de auditoria de caixa de entrada, sincronização de CRM (somente leitura) |
| gmail.enviar | Enviar e-mail em nome do usuário | Sensível | E-mails transacionais do lado do usuário, acompanhamentos de CRM, ferramentas de prospecção |
| gmail.escrever | Criar, ler, atualizar, excluir rascunhos; enviar mensagens | Sensível | Integrações de composer de e-mail, gerenciamento de rascunhos |
| gmail.modificar | Ler, enviar, modificar (rótulos, arquivar) - sem excluir | Restrito | Gerenciamento completo da caixa de entrada, sincronização de CRM com gravação, fluxos de trabalho de arquivamento |
| mail.google.com | Acesso total - ler, escrever, excluir, configurações | Restrito | Clientes de e-mail com todos os recursos, ferramentas de backup, migração de administrador |
| metadados do gmail | Apenas metadados da mensagem (sem corpo) | Não sensível | Análise de volume de e-mail, padrões de remetente/destinatário (sem conteúdo) |
Construindo um SaaS multi-tenant que precisa de `gmail.modify` ou `mail.google.com`? A revisão com escopo restrito adiciona semanas ao seu cronograma de lançamento. Com o Unipile, você pula completamente a revisão da tela de consentimento - o aplicativo OAuth verificado do Unipile cobre os escopos que sua integração precisa.
Construir com UnipileÁrvore de Decisão: Qual Método de Autenticação para o Seu Caso de Uso?
Responda a três perguntas e você saberá exatamente qual caminho de autenticação da API do Gmail se aplica ao seu projeto. Não há uma resposta universal - cada caminho resolve um problema diferente. Para o completo Guia completo de integração com a API do Gmail, Continue para o hub do Gmail. Para o equivalente para Outlook / Microsoft 365, consulte nosso guia de OAuth do Microsoft Graph.
Aplicativo SaaS onde os clientes conectam seu próprio Gmail
Seus usuários são externos (não empregados seus)?
Sim - eles são seus clientes com contas pessoais do Gmail ou do Google Workspace.
Você precisa dar suporte a muitos domínios diferentes do Google?
Sim - multi-tenant. Cada usuário conecta sua própria conta.
Ou Caminho 3 (API Unificada) para pular toda a infraestrutura OAuth.
Ferramenta interna para a sua própria organização do Google Workspace
Todos os usuários pertencem ao mesmo domínio do Workspace (seus funcionários)?
Sim - apenas contas company.com. Sem usuários externos do Gmail.
Você tem um administrador do Workspace que pode configurar o DWD?
Sim - acesso administrativo disponível em admin.google.com.
Sem fluxos de consentimento por usuário. O administrador delega uma vez.
Aplicativo SaaS que precisa de Gmail, Outlook e IMAP sob uma única API
Seus usuários têm uma mistura de contas Gmail, Outlook e IMAP?
Sim - você não pode prever a qual provedor cada usuário se conectará.
Você quer evitar executar integrações OAuth separadas por provedor?
Sim - gerenciar Google OAuth + Microsoft OAuth + IMAP é muita complexidade.
Uma chave de API. Gmail, Outlook, IMAP. Sem operações OAuth.
Comece a criar sua integração com o Gmail hoje mesmo
Não importa qual caminho você escolher, a Unipile te dá uma Visão geral da API unificada de e-mail para entender a arquitetura antes de se comprometer com uma abordagem. Ou vá direto para o painel e conecte sua primeira conta em minutos.
Perguntas frequentes
As perguntas mais comuns sobre autenticação da API do Gmail, chaves de API versus tokens OAuth e como acessar o Gmail programaticamente sem gerenciar o OAuth você mesmo.
Posso usar uma chave de API do Google para acessar o Gmail?
Não. As chaves de API do Google funcionam apenas para APIs públicas e não específicas do usuário, como Maps, Translate ou YouTube Data (conteúdo público). A API do Gmail acessa dados de caixa de correio do usuário particular, que requer consentimento explícito do usuário via OAuth 2.0. Enviar uma solicitação para a API do Gmail com apenas uma chave de API retorna um 401 Login Necessário ou 403 Limite Diário para Uso Não Autenticado Excedido erro - toda vez, sem exceção.
A API do Gmail exige OAuth 2.0?
Sim, sempre. O acesso à API do Gmail é um acesso a dados do usuário, o que significa que toda solicitação deve estar vinculada a um usuário autenticado que concedeu permissão por meio de um fluxo OAuth 2.0. Não há solução alternativa: nenhuma chave de API, nenhuma autenticação básica (descontinuado setembro 2024), sem cabeçalho mágico. Os três caminhos de autenticação suportados são: ID do cliente OAuth 2.0 (multilocatário), Conta de serviço com delegação em toda a domínio (apenas Workspace) e uma API de e-mail unificada como Unipile que lida com a camada OAuth para você.
Qual é a diferença entre uma chave de API e um ID de cliente OAuth no Google Cloud?
Um Chave de API identifica seu projeto do Google Cloud para fins de faturamento e cotas. Ele funciona apenas para APIs que servem dados públicos (Maps, Translate, etc.). Um ID do cliente OAuth é usado para iniciar um fluxo de consentimento onde um usuário real aprova o acesso do seu aplicativo à conta dele. O ID do cliente OAuth gera o token de acesso e o token de atualização que a API do Gmail realmente aceita. Estes são dois mecanismos completamente diferentes: um identifica um projeto, o outro autentica um usuário.
Uma conta de serviço pode ler e-mails do Gmail sem o consentimento do usuário?
Somente se Delegação em Toda a Empresa (DWD) é habilitado por um administrador do Google Workspace. Uma conta de serviço por si só não pode acessar nenhuma caixa de entrada do Gmail. Com o DWD configurado, a conta de serviço pode se passar por qualquer usuário na organização e acessar sua caixa de correio sem consentimento interativo. Limitação crítica: isso funciona apenas para contas do Google Workspace (corporativas). Não funciona para endereços de e-mail pessoais do Gmail (@gmail.com). Veja Documentação oficial do DWD do Google.
Por que a API do Gmail retorna "Login Required" com minha chave de API?
Porque A API do Gmail não aceita chaves de API. O 401 Login Necessário erro significa que a solicitação não possui um token de acesso OAuth 2.0 válido no Authorization cabeçalho. A API do Gmail espera: Autorização: Bearer {access_token} - onde o token de acesso foi obtido via um fluxo OAuth 2.0 (código de autorização, JWT de conta de serviço ou um token de API unificado). Simplesmente anexando ?chave=SUA_CHAVE_DE_API a URL da API do Gmail não funcionará e retornará 401 ou 403.
Existe uma maneira de usar a API do Gmail sem gerenciar o OAuth sozinho?
Sim. Uma API de e-mail unificada como Unipile gerencia toda a camada OAuth: a tela de consentimento, a troca de tokens e a rotação silenciosa de tokens de atualização. Sua aplicação nunca armazena ou gerencia tokens de acesso ou tokens de atualização. Você chama a API Unipile com sua própria chave de API, e a Unipile lida com toda a comunicação OAuth com o Google em nome da sua Contas vinculadas. Isso remove o processo de aprovação da tela de consentimento do Google e a complexidade do gerenciamento de tokens do seu código – e oferece Gmail, Outlook e IMAP sob uma interface unificada.
BR 
EN 
FR 
ES 
DE 
IT 
NL 
PL 
TR