Estou enfrentando um obstáculo frustrante no n8n Cloud ao tentar construir um Agente IA (conectado a um agente de voz ElevenLabs) que verifica disponibilidade e cria eventos em um Google Agenda específico.
Parece que estou preso em um dilema de Catch-22 relacionado à autenticação, e espero que alguém aqui tenha uma solução.
O Objetivo
Tenho um workflow com um nó Agente IA conectado a nós de ferramentas do Google Agenda (“Get many events” e “Create an event”). O agente precisa ler slots livres/ocupados e agendar compromissos em um agenda específica.
Tentativa 1: Usando o OAuth Gerenciado Padrão (Sign in with Google) Usei a credencial padrão “Google Calendar account” no n8n Cloud. Cliquei em “Sign in with Google”, e conectou com sucesso (mostrando o status verde “Account connected”).
O Problema: Mesmo dizendo que está conectado, o Agente IA falha consistentemente em ler ou escrever na agenda. Parece ser um problema de escopo ou permissão, pois o agente simplesmente não consegue acessar os dados apesar do status de conexão verde.
Tentativa 2: Criando um App Personalizado no Google Cloud Console Seguindo vários tutoriais para corrigir esses problemas de permissão/escopo, entrei no Google Cloud Console, criei um projeto dedicado, habilitar a Calendar API, configurei a tela de consentimento OAuth e gerei meu próprio Client ID e Client Secret.
O Bloqueio: Porque estou no n8n Cloud (não auto-hospedado), a configuração de credencial nativa “Google Calendar account” esconde completamente os campos Client ID e Client Secret. Ela me força a usar o OAuth gerenciado do n8n. Não há toggle ou opção para inserir minhas credenciais GCP personalizadas no nó Agenda nativo.
Tentativa 3: Usando a Credencial Google OAuth2 Genérica Para contornar isso, tentei criar uma credencial genérica “Google OAuth2 API”. Esta configuração permite que eu insira meu Client ID e Client Secret personalizados.
O Bloqueio: Os nós nativos de ferramentas do Google Agenda conectados ao meu Agente IA recusam aceitar este tipo de credencial genérico. Eles exigem estritamente o tipo de credencial específico “Google Calendar account”.
Minhas Perguntas
Como posso forçar o nó de credencial nativo do Google Agenda no n8n Cloud a aceitar um Client ID e Client Secret personalizados? Existe uma configuração oculta para desabilitar o OAuth gerenciado?
Se o OAuth personalizado é estritamente impossível no n8n Cloud para estes nós nativos, por que o agente IA está falhando em ler/criar eventos quando usa a configuração gerenciada “Sign in with Google”, mesmo quando mostra como conectado? (A agenda é apropriadamente compartilhada com direitos de edição para a conta autenticada).
Parece que a interface está me impedindo de usar a configuração técnica adequada, enquanto a configuração gerenciada “simples” não dá ao agente IA o acesso real que ele precisa.
Qualquer orientação seria muito apreciada!
PS: se houver algo FÁCIL porque neste estágio não entendo por que o N8N criou um Nó Google Agenda “Create Event” se não consegue funcionar apenas fazendo login com um login básico do Google Agenda.
Bem-vindo @JCBuildsAI à nossa comunidade! Sou Jay e sou um criador verificado da n8n.
A credencial gerenciada “Sign in with Google” na n8n Cloud usa escopos que cobrem acesso básico ao Calendar, mas as ferramentas de nós do AI Agent podem precisar de escopos específicos como https://www.googleapis.com/auth/calendar.events para realmente escrever eventos. Quando conectado mas falhando, geralmente esse é o culpado. A solução alternativa é desconectar e reconectar a credencial do Google Calendar, mas desta vez verifique quais escopos estão sendo solicitados durante a tela de consentimento do OAuth - se o escopo de escrita do calendar não estiver na lista, você precisará criar um novo projeto do Google Cloud com um aplicativo OAuth personalizado, definir os escopos necessários manualmente e então usar o tipo de credencial “Google Calendar OAuth2 API” na n8n (não a conta padrão “Google Calendar”) que expõe campos de Client ID/Secret mesmo na Cloud.
Oi Jai, obrigado pelo vídeo, tentei explicar no meu email aqui onde estou travado: Link do vídeo
Depois de criar o projeto Google Cloud, você não consegue criar uma API OAuth2 do Google Calendar com credenciais como você mencionou, nem no plano standard ou pro
Veja a screenshot, não há nada que você possa fazer aqui - alguma ideia depois de verificar meu vídeo?
oi eu acabei de postar esse vídeo sua proposta de migrar para o plano pro ou standard não muda nada - veja o vídeo: Link Video - você poderia verificar e me dar sua opinião?
No Google Cloud Console, você não cria uma “Google Calendar OAuth2 API” - isso não existe lá. O que você precisa fazer é: vá para APIs & Services > Credentials > Create Credentials > OAuth Client ID, escolha Web Application como tipo, depois defina o redirect URI para aquele que o n8n fornece na tela de configuração de credenciais. Isso vai te dar o Client ID e Client Secret para colar na credencial “Google Calendar OAuth2 API” do n8n. Certifique-se de que a Google Calendar API está habilitada em APIs & Services > Enabled APIs primeiro. Se você está vendo a página de credenciais sem a opção de criar OAuth Client ID, verifique se completou a configuração da tela de consentimento OAuth em APIs & Services > OAuth consent screen.
Obrigado, como você pode ver neste vídeo, ele usa um N8N auto-hospedado e não a solução N8N hospedada, que não possui os campos disponíveis. Basicamente, acredito que não está funcionando no N8N hospedado
@JCBuildsAI funciona sim no n8n Cloud - o tipo de credencial “Google Calendar OAuth2 API” no n8n tem campos para Client ID e Client Secret tanto na Cloud quanto no self-hosted. O que você precisa fazer é criar o OAuth Client ID no Google Cloud Console (não dentro do n8n), depois colar esses valores na credencial do n8n. Os passos que descrevi anteriormente se aplicam exatamente da mesma forma na Cloud. Você pode compartilhar uma captura de tela do que você vê quando abre a credencial “Google Calendar OAuth2 API” no n8n? Isso ajudaria a confirmar onde está a confusão.
@JCBuildsAI o método que @nguyenthieutoan sugeriu definitivamente funcionará. Eu também criei algo similar, mas na versão self-hosted. Você só precisa criar a credencial de API OAuth2 no console do Google, não no n8n, e deve funcionar.
Eu já encontrei esse padrão exato antes. O OAuth gerenciado no n8n Cloud deveria funcionar — o problema é quase sempre um desses dois:
Mais provável: incompatibilidade de escopo durante o fluxo de consentimento do OAuth.
Quando você clicou em “Entrar com o Google”, a tela de consentimento pode não ter solicitado todos os escopos do Calendário que o AI Agent precisa. Tente isto:
Vá para sua Conta Google → Segurança → Aplicativos de terceiros com acesso à conta
Encontre a conexão n8n e remova-a completamente
De volta ao n8n, delete a credencial existente do Google Calendar
Crie uma nova e faça login novamente — desta vez observe a tela de consentimento com atenção e garanta que você conceda todas as permissões solicitadas (ler, escrever, gerenciar calendários)
A reautenticação força o Google a reprompt os escopos em vez de reutilizar silenciosamente uma concessão desatualizada.
Se isso não funcionar: incompatibilidade de propriedade do calendário.
O OAuth autentica como sua conta do Google, mas o AI Agent pode estar tentando acessar um calendário que foi compartilhado com você em vez de ser de sua propriedade. Verifique qual ID de calendário específico os nós de ferramentas estão direcionando — se for um calendário compartilhado, você precisa de permissão explícita “Fazer alterações em eventos”, não apenas “Ver todos os detalhes de eventos”.
Workaround para Tentativa 3 (OAuth genérico + AI Agent):
Você está certo que os nós nativos do Calendário rejeitam a credencial genérica. Mas você pode construir a mesma funcionalidade usando nós HTTP Request com sua credencial genérica Google OAuth2, chamando a API do Calendário diretamente:
conecte esses nós HTTP Request como ferramentas no seu AI Agent — o Agent não se importa se a ferramenta é um nó nativo ou um HTTP Request, ele apenas vê o schema de entrada/saída.
Essa abordagem também lhe dá controle total sobre tratamento de erros e lógica de tentativas, o que você vai querer de qualquer forma uma vez que isso estiver lidando com reservas reais.
