YouTube, Gmail, Drive, Planilhas, Analytics, Search Console, Custom Search: quase tudo no Google tem API. O problema não é faltar endpoint. É o Cloud Console virar um depósito de projetos, chaves e contas, cada uma ligada a um app diferente. Eu montei um conector OAuth que centraliza isso na minha Cloudflare. O repositório está no GitHub. A ideia importa mais que a ferramenta: um autenticador seu, com as contas que você autorizar, conversando com a IA sem gerar chave a cada script.
Hospede o Google Connector na sua Cloudflare, cadastre o cliente OAuth do Google Cloud, marque os scopes no portal e conecte cada conta uma vez. A IA e os scripts pedem o access token renovado no Worker, em vez de carregar uma chave nova por aplicação.
- Repositório
- github.com/kevinbkt10/google-connector
- Onde roda
- Cloudflare Workers + D1
- O que autoriza
- OAuth com scopes por conta
A bagunça começa no Cloud Console, não na API
No Google Cloud eu contei mais de 531 integrações. Dá para publicar vídeo, ler e-mail, mandar foto, consultar visita, puxar consulta do Search Console e automatizar planilha. Cada serviço pede projeto, credencial e, no OAuth, um conjunto de scopes. Quando você troca de conta, ou quando um script novo aparece, a tentação é criar outra chave. Em pouco tempo ninguém sabe qual cliente fala com qual propriedade.
Eu já usava a mesma ideia no Facebook para mandar postagem ao Instagram. Passei o desenho para o Google. Pretendo repetir em contas que aceitam login OAuth, inclusive da Apple. O conector não substitui a API. Ele guarda a autorização. A IA, ou um programa local, chama o Worker, recebe o token vigente e fala com o YouTube ou com o Analytics como se tivesse acabado de logar.
Não é um produto multi-tenant para o público. Cada pessoa instala o próprio Worker, com o próprio Client ID. Se você não quiser baixar o meu código, o vídeo mostra o caminho para pedir à IA que monte um igual: portal de contas, lista de permissões, callback OAuth, banco para o token. O GitHub existe para quem prefere começar pronto.
OAuth, scopes e o que cada permissão libera
OAuth não é chave de API. Chave de API identifica um projeto. OAuth pede à pessoa que autorize um acesso concreto, com um scope. Scope é uma URL que descreve o serviço e o nível: só ler Analytics, ou também publicar no YouTube, ou ler e apagar Gmail. O Google marca muitos desses scopes como sensíveis ou restritos. Aplicativo público que pede dado de usuário precisa passar por verificação. App em teste, para a sua conta, continua funcionando com o aviso de não verificado.
No portal do conector eu listo os scopes disponíveis. Se faltar uma API, eu peço à IA para incluir a URL nova no projeto. Aí a tela de conectar passa a pedir aquela permissão. Eu posso ligar várias contas Google, cada uma com um identificador. Não gero chave de API por conta. Reconectar existe para quando eu mudo o conjunto e a conta antiga ficou com autorização incompleta.
O Google recomenda o scope menor que resolve a tarefa. youtube.upload publica. analytics.readonly lê relatório. gmail.readonly lê caixa. drive.file mexe só nos arquivos que o app criou. mail.google.com lê, escreve e apaga a caixa inteira: use se a automação realmente precisa disso. No vídeo eu aceitei o pacote para mostrar o fluxo. No uso diário eu marcaria só o que a conta vai fazer.
- YouTube: https://www.googleapis.com/auth/youtube.upload para enviar vídeo; youtube.force-ssl para ler e editar dados do canal pela API.
- Analytics: https://www.googleapis.com/auth/analytics.readonly para consultar relatórios sem escrever propriedade.
- Search Console: https://www.googleapis.com/auth/webmasters.readonly para ler dados do site; webmasters se a automação também alterar propriedade.
- Gmail: https://www.googleapis.com/auth/gmail.readonly para leitura; gmail.modify para apagar ou alterar mensagem; o scope mail.google.com é o mais amplo.
- Drive e Planilhas: https://www.googleapis.com/auth/drive.file para arquivos do app; spreadsheets para a planilha; drive completo só se a tarefa precisar de tudo.
- Google Photos: scopes da Photos Library para envio e leitura de mídia, quando essa API estiver ligada no projeto.
- Custom Search: a consulta de busca costuma ir por chave de API do Programmable Search, não por OAuth de usuário; no conector ela entra se você configurar essa credencial à parte.
O portal: contas, permissões e o aviso de app não verificado
A tela de contas pede um ID para você reconhecer a conexão, por exemplo principal, e o botão Conectar ao Google. Abre o consentimento. Como o cliente OAuth está em desenvolvimento, o Google mostra o aviso de app não verificado. Isso não é bug do conector. É o comportamento documentado para app que pede scope sensível e ainda não passou na verificação. Em Avançado, você segue para o app. Na lista, marca o que autoriza: ver e editar YouTube, ler Gmail, mandar foto, e o restante que o portal pediu.
Verificação do Google entra quando outras pessoas, fora do grupo de teste, forem logar. App interno da mesma organização Workspace também pode ficar sem essa etapa. Para uso próprio, o aviso é o preço de não enviar o app para análise. O teto de usuários novos em app não verificado existe; para uma ou duas contas suas, não é o bloqueio.
Depois de aprovar, o portal mostra as permissões daquela conta. Reconectar abre o mesmo fluxo se você acrescentou scope. Quantas contas quiser, cada uma com o próprio token. O Worker guarda o material criptografado no D1. A IA não vê a senha do Google. Ela pede o access token vigente na rota de runtime.
- No Google Cloud, crie um projeto, ative as APIs que for usar e monte a tela de consentimento OAuth (tipo Externo, se a conta for Gmail pessoal).
- Crie um cliente OAuth de Aplicativo da Web. Redirect URIs: https://SEU_WORKER/callback e, em local, http://localhost:8787/callback.
- No conector, abra /portal com o CONNECT_TOKEN. Na aba de permissões, marque só os scopes da tarefa e salve.
- Na aba de contas, defina uma chave (por exemplo principal) e clique em Conectar ao Google.
- Se aparecer app não verificado, use Avançado e siga. Confira cada permissão antes de aceitar.
- Volte ao portal e confirme que a conta listou os scopes. Se faltar algum, reconecte depois de salvar a lista nova.
Instalar pelo GitHub e publicar na Cloudflare
O repositório é google-connector, em github.com/kevinbkt10/google-connector. Tem README, tutorial na página e um AGENTS.md para a IA seguir. Eu baixei, descompactei e abri a pasta no chat. Pode ser Codex, Claude, Grok, o que você já usa. Eu estava no Grok, numa interface que não é CLI, só para gravar com menos fricção. Antes de deixar a IA mexer, quem desconfiar do código pode pedir uma leitura em busca de coisa estranha. Eu publiquei o template para quem me segue, não como atalho para baixar qualquer GitHub.
O pedido que eu fiz foi falado, com erro e tudo: conectar na Cloudflare, criar um subdomínio, reaproveitar dados do Google Cloud que eu já tinha em outro conector, fazer o deploy. A IA errou o domínio na primeira vez. Eu corrigi. Não mostrei as credenciais na tela. O caminho manual, se você não quiser improvisar, está no README: wrangler login (ou o API Token do outro vídeo), criar o D1, colar o database_id no wrangler.jsonc, colocar GOOGLE_CLIENT_ID e APP_BASE_URL, rodar o schema, gravar os secrets e dar deploy.
Secrets que o template pede: GOOGLE_CLIENT_SECRET, STATE_SIGNING_SECRET, ACCOUNT_ENCRYPTION_SECRET, ADMIN_API_TOKEN e CONNECT_TOKEN. CONNECT_TOKEN entra no painel. ADMIN_API_TOKEN entra na API que a IA chama. Depois do deploy, APP_BASE_URL e o redirect do Google Cloud precisam ser a URL real mais /callback. Sem isso o OAuth volta para o lugar errado.
- Clone ou baixe https://github.com/kevinbkt10/google-connector e abra a pasta no chat da IA, ou siga o README no terminal.
- Crie o banco: npx wrangler d1 create google-services-connector. Cole o database_id em wrangler.jsonc.
- Preencha GOOGLE_CLIENT_ID e APP_BASE_URL. A URL de callback no Google Cloud deve ser APP_BASE_URL + /callback.
- Aplique o schema: npx wrangler d1 execute google-services-connector --remote --file=schema.sql.
- Grave os secrets com wrangler secret put: GOOGLE_CLIENT_SECRET, STATE_SIGNING_SECRET, ACCOUNT_ENCRYPTION_SECRET, ADMIN_API_TOKEN, CONNECT_TOKEN.
- Publique com npx wrangler deploy. Abra /health e depois /portal. A IA do projeto chama GET /accounts/CHAVE/runtime com o ADMIN_API_TOKEN.
O que eu já fiz com o conector: YouTube e Analytics
Enquanto o deploy de demonstração rodava, eu mostrei dois usos reais. No primeiro, enviei um vídeo com uma instrução para a IA cuidar da publicação. O conector localizou o canal. O vídeo saiu com título, descrição, tags, capítulos, miniatura e legendas em SRT, em mais de um idioma. Sem o OAuth unificado, cada uma dessas chamadas pediria o mesmo consentimento espalhado em scripts.
No segundo, pedi para localizar no Analytics as páginas que respondiam 404 e comparar com o site atual, para achar link interno quebrado. Tudo no chat. A IA entrou pela API, via conector, e trouxe a lista. O mesmo desenho serve para Search Console e para consulta no Custom Search, no estilo de um MCP: você pede o dado e o site, sem abrir cada painel.
A stack é Worker mais D1. wrangler.jsonc define o projeto. O banco guarda a conta e o token criptografado em AES-GCM. Dá para adaptar para Vercel ou outro host; aí a IA precisa trocar o runtime. O que eu quero que fique é o desenho: uma autorização Google, vários serviços, token renovado no seu servidor, não uma chave por aplicativo no notebook.
Na sequência
- Ativar no Google Cloud só as APIs que a conta vai usar.
- Registrar o redirect https://SEU_WORKER/callback no cliente OAuth.
- Marcar scopes mínimos no portal antes de clicar em Conectar.
- Separar CONNECT_TOKEN (painel) de ADMIN_API_TOKEN (API da IA).
- Confirmar /health, conectar uma conta de teste e chamar /accounts/CHAVE/runtime.
Onde isso quebra
Pedir todos os scopes de uma vez em um cliente que você ainda não verificou. O aviso de app não verificado é esperado; o excesso de permissão não é.
Deixar APP_BASE_URL diferente do redirect do Google Cloud. O login volta com erro de URI, não de senha.
Colocar Client Secret no repositório. O template já nasce sem credencial de ninguém.
Tratar o Worker como serviço público multi-tenant. Cada instalação é da sua conta Cloudflare e das suas contas Google.
Perguntas frequentes
Por que o Google mostra que o app não foi verificado?
O cliente está em modo de teste e pede scopes sensíveis. Isso é o fluxo documentado. Em Avançado você segue para a sua conta. Verificação entra se outras pessoas, fora do grupo de teste, forem autorizar o app.
Preciso de uma chave de API para cada serviço do Google?
Não neste desenho. Você autoriza a conta uma vez, com os scopes marcados. A IA pede o access token no Worker. Chave de API continua existindo para serviços que não usam OAuth de usuário, como muita consulta do Custom Search.
Onde o token do Google fica guardado?
Criptografado no D1 da sua Cloudflare, com ACCOUNT_ENCRYPTION_SECRET. O painel usa CONNECT_TOKEN. Scripts e IA usam ADMIN_API_TOKEN na rota /accounts/:chave/runtime, que devolve o token renovado.
Consigo acrescentar uma API que não veio no portal?
Sim. No vídeo eu digo para pedir à IA que inclua o scope novo no projeto. Depois você marca a permissão, reconecta a conta e o consentimento pede o item extra.
Funciona fora da Cloudflare?
O template nasceu para Workers e D1. O README e o wrangler.jsonc assumem isso. Levar para Vercel ou outro host é adaptação de runtime, banco e secrets, não de OAuth. O consentimento do Google continua igual.