A demo nunca mostra essa parte. Uma ferramenta de vibe coding gera, em um único prompt, um botão elegante de “Conecte seu Google Calendar”, e parece pronto. O que a demo pula é tudo que fica entre clicar nesse botão e o calendário realmente sincronizar: uma aplicação de desenvolvedor registrada na console do provedor, credenciais OAuth configuradas, redirect URIs definidos e, em alguns casos, uma etapa de verificação de domínio que não tem nada a ver com a lógica do seu app e tudo a ver com provar que você é dono do domínio em que está construindo.
Essa é a parte do vibe coding para a qual não existe prompt. Você não consegue descrever seu caminho para contorná-la, porque o provedor (Google, Slack, Stripe, seja qual for) exige as mesmas etapas de registro de um criador solo que exige de uma equipe de engenharia.
O que “conecte seu calendário” realmente exige
Para uma integração como o Google Calendar, não existe uma API key que você simplesmente cole em um campo de configuração. O código gerado precisa de uma identidade real, registrada junto ao provedor, antes de poder pedir a alguém que autorize qualquer coisa. Na prática, isso significa:
- Criar uma aplicação de desenvolvedor na console do provedor (Google Cloud Console, o painel de apps do Slack, o portal de desenvolvedores da Stripe).
- Configurar credenciais OAuth para essa aplicação: um client ID e um secret que identificam seu app junto ao provedor.
- Definir redirect URIs que correspondam exatamente ao lugar para onde o provedor deve devolver o usuário após a autorização, até o protocolo e a barra final.
- Concluir a verificação de domínio, quando o provedor exige prova de que você controla o domínio em que o app roda antes de liberar acesso em nível de produção.
- Selecionar e solicitar scopes, as permissões específicas que o app está pedindo, que são revisadas (às vezes pelo provedor, às vezes só por quem está construindo o app com pressa).
Nada disso é lógica de aplicação. É administração de conta na plataforma de outra empresa, e precisa ser feito corretamente antes que um único evento de calendário apareça na interface gerada.
Duas formas de errar os scopes, ambas ruins
Os scopes são o ponto em que isso deixa de ser apenas tedioso e passa a ser arriscado. Errar em qualquer uma das direções produz uma falha completamente diferente.
Scopes demais é a falha de segurança. Pedir acesso total ao Drive quando a funcionalidade só precisava de eventos do Calendar em modo leitura não é um atalho, é um risco permanente: todo arquivo daquela conta agora fica acessível por meio de uma credencial que o app nunca precisou tocar. Isso fica ali, quieto, até o dia em que um token vaza ou uma sessão é comprometida, e nesse momento o raio de impacto é o scope completo concedido, não a funcionalidade que de fato foi construída. É o mesmo tipo de problema dos 45% do código gerado por IA que carrega vulnerabilidades de classe OWASP: o código roda bem e faz uma demo perfeita enquanto a exposição fica por baixo, invisível até que algo dê errado.
Scopes de menos é o modo de falha silenciosa. Falta um único scope necessário e a integração não lança um erro claro, ela simplesmente para de funcionar de um jeito difícil de diagnosticar. Uma sincronização de calendário que não retorna nada, uma notificação do Slack que nunca é enviada, um webhook da Stripe que dispara mas cujo handler não consegue ler o campo de que precisa. Um criador não técnico encarando um resultado vazio não tem como saber se o bug está no código gerado, na configuração dos scopes ou do lado do provedor, e a IA não consegue inspecionar a concessão OAuth para dizer isso a ele.
Acertar exatamente a lista de scopes, e revisá-la cada vez que o conjunto de funcionalidades muda, é uma habilidade específica e estreita. Não é algo coberto pelo prompting de “descreva o que você quer”, porque a IA que gera o código de integração não controla o que a console do provedor vai de fato autorizar.
Onde as credenciais acabam vivendo
Uma vez que a dança do OAuth funciona, o client ID, o secret e quaisquer tokens de acesso resultantes precisam viver em algum lugar. Esse “algum lugar” é uma decisão de arquitetura real, não um detalhe. Testar a integração localmente significa que o app precisa de variáveis de ambiente apontando para credenciais reais, e criadores não técnicos que não sabem gerenciar arquivos .env corretamente costumam, em vez disso, escrever esses valores direto no código, fixos. Secrets fixos no código que acabam sendo enviados por acidente para um repositório público do GitHub acontecem com frequência suficiente para ser um modo de falha documentado e nomeado de toda a categoria, não um erro raro. Depois que um secret entra no histórico de um repositório público, rotacioná-lo e confirmar que nada explorou essa janela é um trabalho de limpeza próprio, além da integração que você estava tentando entregar.
Encanamento, não produto
Vale a pena chamar isso pelo nome certo: trabalho de infraestrutura, não a funcionalidade que você estava tentando construir. Ninguém acorda com vontade de configurar um redirect URI. A necessidade de negócio era “mostrar as próximas reuniões do cliente” ou “avisar a equipe no Slack quando um negócio for fechado”. A console OAuth, a lista de scopes e o armazenamento de credenciais são o custo inevitável para chegar lá numa plataforma em que cada integração é construída do zero, e escalam com o número de serviços de terceiros que o app toca, não com o quão polida a funcionalidade parece.
É exatamente aqui que uma plataforma como o Softr é a ferramenta certa para o trabalho, e não uma solução paliativa. Seus conectores nativos para Google Calendar, HubSpot, Stripe e ferramentas de negócio semelhantes são aplicações OAuth pré-verificadas e já aprovadas: o criador autoriza sua conta em um fluxo de login, e os scopes e o armazenamento de credenciais são tratados no servidor, totalmente fora do cliente, porque o Softr já fez o registro na console uma vez para todo mundo. Mas para um portal de clientes ou uma ferramenta interna cuja tarefa é basicamente “sincronizar um calendário e postar no Slack”, o imposto da integração é o tipo de encanamento que é mais barato comprar como infraestrutura de plataforma do que reinventar a cada projeto.
Essa troca deixa de fazer sentido no momento em que a própria integração é o produto. Se você está conectando um provedor para o qual ninguém tem um conector, ou precisa de controle sobre a renovação de tokens e o tratamento de erros, você quer ser dono do fluxo OAuth em vez de herdar o de outra pessoa. Isso é trabalho de desenvolvedor, e pertence a ferramentas de desenvolvedor: Cursor dentro de uma base de código real, onde você pode ler o que as credenciais realmente fazem, ou Replit, onde variáveis de ambiente e gestão de secrets são de primeira classe em vez de algo encaixado depois. Nenhum dos dois elimina o registro na console, porque nada elimina. Eles apenas colocam você em posição de acertar os scopes de forma deliberada, em vez de descobri-los por tentativa e erro.
O loop de correções piora isso com o tempo, não melhora. Cada ajuste de scope ou nova integração é mais uma rodada de configuração na console, mais um redirect URI para acertar exatamente, e mais uma chance de conceder demais ou de menos. É um custo que se acumula a cada funcionalidade adicionada, que é exatamente a forma do problema do Dia Dois: o app que fez uma demo impecável no primeiro dia continua gerando novo trabalho de encanamento a cada vez que cresce.