Como automatizar o upload no YouTube com login Google e IA na Cloudflare

A mesma ideia do Instagram: login, não uma chave por pessoa

No Facebook, chave de API por conta era um inferno: expirava rápido, no outro dia já tinha caído. No Instagram eu passei a logar a conta, ganhar a permissão de publicar, e repetir isso para quantas contas eu quisesse. No YouTube eu quis o mesmo. Vantagem extra: consigo conectar conta que nem está no meu Google Cloud. Eu abri o Antigravity e pedi um site online na Cloudflare Workers para logar pelo Google, ligar o canal e enviar vídeo por esse login, sem API por conta. HTML puro, no máximo uma camada pequena como HTMX. Não testei o caminho “uma chave de API do YouTube por canal”. Talvez a API isolada seja até melhor em cota. No Facebook não era.

Expliquei que o chat da IA seria a mesa de envio. Ele criou a tela, o scope, o login. A parte que continua humana é o Console do Google e o secret na Cloudflare. O resto a ferramenta monta se o Wrangler da sua conta já estiver autenticado — a minha já estava, então D1 e Worker nasceram sozinhos.

Google Cloud: client ID, secret e callback

No Google Cloud Console, APIs e serviços, credenciais: crie um ID de cliente OAuth 2.0. Copie o ID. Gere a chave secreta do cliente. Coloque a URL de callback — a minha era a rota de callback do Worker. Mande o ID para a IA colocar no projeto. Não mande o secret no chat se puder evitar.

Na Cloudflare, o Worker que a IA criou já tinha D1. Em configurações, secret fica na conta, não no wrangler.jsonc, não num .env que viaja no Git. Se você criar a variável como texto simples no painel, um deploy seguinte pode apagar o valor. Secret permanece. O nome da variável a própria IA indica na hora do projeto. Client ID pode ir no arquivo de config; client secret, não.

1. Crie o cliente OAuth 2.0 no Google Cloud e anote o ID.
2. Gere o client secret uma vez e trate como segredo.
3. Cadastre a URL de callback HTTPS do Worker, a mesma que o código espera.
4. No Worker, grave o secret no painel da Cloudflare; não cole no wrangler.jsonc.
5. Confira se o YouTube Data API v3 está ligado no projeto do Console.

Conectar a conta com um ID interno

Com o site no ar, você conecta uma conta Google e escolhe um ID interno — no teste, midplay. Esse apelido é o que você manda no chat: publica neste ID. O login mostra o aviso de app não verificado se você ainda não mandou o aplicativo para aprovação. Eu tinha mandado e ainda esperava. Conta de teste funciona; quem loga revisa as permissões e aceita mesmo assim. A expiração, em app de teste, parece mais curta. Eu pedi uma conexão mais duradoura. A tela ainda falava em expirar no mesmo dia; a IA disse que fez renovação. Na gravação isso era aposta, não prova de meses.

O primeiro envio real: Python faltando, broker em localhost, 2 MB

Eu abri o Codex, não o Antigravity em que o projeto nasceu, e mandei publicar. Os nomes dos arquivos já diziam o recorte: canal de piano em estilo sinestesia, Midplay. Pedi para gravar isso num M.md do canal, para os próximos envios. Música do Michael Jackson, título e descrição em inglês, nome da música, artista, piano, tutorial, Midplay, link da faixa no site, tags. A conta já estava conectada.

A execução travou: o ambiente sem as dependências Python mínimas do script. A IA isolou um ambiente só para publicar, sem mexer no código do projeto — eu até preferia que mexesse. Em seguida o broker de checkout apontava para localhost 8787, enquanto a conta Midplay estava válida no broker de produção. Ela validou título, descrição e tag de verdade. Eu tinha pedido público. Ela subiu privado. Pedi a troca depois.

Passou de 80% e o YouTube recusou a miniatura: mais de 2 MB. A documentação da plataforma limita a miniatura personalizada a dois megabytes, JPEG, GIF, PNG ou BMP. A IA gerou uma cópia comprimida e reenviou. Esse é o tipo de ida e volta que, na mão, come a tarde. No chat você manda e faz outra coisa — até o ponto em que a permissão não cobre o que você pediu.

• Script local em Python: instale as dependências no ambiente que vai publicar, não só no Worker.
• URL de broker: produção e localhost 8787 não são a mesma conta.
• Miniatura: comprima abaixo de 2 MB antes, ou aceite o retrabalho na hora.
• Visibilidade: se quiser público, peça no upload; mudar depois depende de scope e de política da API.

Privado, público e o atalho do navegador que eu recusei

O link chegou. Eu perguntei se dava para mudar de privado para público. A ideia de ter a IA no ar, de qualquer lugar, pedindo publicação, é exatamente o que eu queria. Talvez o YouTube lance isso nativo um dia. Enquanto não lança, a pasta com vários arquivos e um “a cada seis ou oito horas publique um” é o próximo degrau — vários chats, vários canais, vários agentes. Na gravação isso era desejo, não job que eu tenha mostrado rodando.

No Studio o último vídeo continuava sem o status que eu queria. A IA perguntou em vez de publicar. Depois disse que conseguia mudar a tela final pelo navegador interno. Eu não recomendo: o token da API não tinha permissão para trocar visibilidade depois do upload. Será que antes do upload teria. Eu deixei o teste para depois. Já tinha postado um vídeo naquele dia. O recado útil: automação de envio não é automação de status. Scope de upload e scope de gerenciar o vídeo não são o mesmo pedido no consentimento — o vídeo seguinte, de revisão de canal, entra exatamente nisso.

Grupo de WhatsApp na descrição, Cloudflare Workers e IA, o convite do fechamento. O sistema estava no ar o suficiente para o próximo vídeo nascer privado e ainda assim existir.

Na sequência

1. Cliente OAuth no Google Cloud com callback HTTPS do Worker.
2. Client secret como secret da Cloudflare, client ID no config.
3. YouTube Data API v3 habilitada no projeto.
4. Cada canal com ID interno e login testado em modo de teste.
5. Miniatura abaixo de 2 MB e visibilidade definida no pedido de upload, não só depois.

Onde isso quebra