Automação entre sistemas: o que decidir antes de conectar A com B

Automação entre sistemas não é, na prática, "conectar A com B". É decidir onde mora a verdade quando os dois lados podem estar certos ao mesmo tempo: o CRM diz que o negócio fechou, o banco de dados ainda não sabe disso, e alguma automação no meio precisa garantir que os dois concordem sem duplicar nem perder informação.

Depois de anos ligando sistemas diferentes (CRM, banco próprio, WhatsApp, planilha, e-mail) numa stack real, essas são as decisões que importam antes de sair conectando webhook em tudo.

Webhook, polling ou fila

A primeira decisão, e a mais ignorada, é como um sistema avisa o outro que algo mudou.

Webhook é a opção certa quando o sistema de origem oferece o recurso e você precisa de reação quase instantânea (um pagamento aprovado, uma mensagem de WhatsApp recebida). O problema: se o seu servidor estiver fora do ar no exato segundo em que o webhook chega, o evento pode se perder pra sempre, a menos que o sistema de origem faça retry sozinho (nem todos fazem).

Polling (perguntar de tempos em tempos "mudou alguma coisa?") é mais lento, mas mais resiliente: se a automação cair por uma hora, ela pega tudo que passou assim que voltar. Faz sentido quando o sistema de origem não tem webhook, ou quando o atraso de alguns minutos não importa.

Fila (Redis, RabbitMQ, ou até uma tabela de banco fazendo esse papel) entra quando o volume é alto ou quando o processamento de cada evento pode demorar. Em vez do webhook processar tudo na hora e travar se algo demorar, ele só empilha o evento e devolve resposta rápida pra quem chamou. Um worker separado consome a fila no próprio ritmo.

Não existe escolha certa universal: existe a pergunta "o que acontece se esse evento se perder ou chegar atrasado", e a resposta define qual dos três você precisa.

Idempotência: a automação não pode ter memória curta

Esse é o ponto onde a maioria das automações que eu já vi quebrar, quebrou. Se um webhook é reenviado (e gateways de pagamento, WhatsApp e a maioria dos CRMs reenviam sim, isso é esperado, não bug), a sua automação processa esse mesmo evento duas vezes. Se a ação for "criar um registro", agora tem um duplicado. Se for "cobrar um cliente", pior ainda.

A solução é sempre a mesma: toda automação que executa uma ação (não que só lê) precisa de uma chave de idempotência: um identificador único do evento (o próprio ID do webhook, ou um hash do conteúdo) que você guarda antes de agir e checa antes de agir de novo. Se a chave já existe, você responde "ok" sem repetir a ação.

Isso vale tanto pra criar quanto pra atualizar. "Se não existe, cria" parece inofensivo, mas duas execuções simultâneas do mesmo evento podem checar "não existe" ao mesmo tempo e criar dois registros antes que qualquer uma das duas termine de escrever. A checagem e a escrita precisam estar dentro da mesma transação, ou usar uma constraint única no banco que rejeita o duplicado na marra.

Retry e backoff: o outro sistema vai cair, e está tudo bem

Todo sistema externo cai em algum momento: API de pagamento, CRM, servidor de e-mail. A pergunta não é "como evitar isso", é "o que a minha automação faz quando isso acontece".

Retry sem controle é tão perigoso quanto não ter retry: se a chamada falha e você tenta de novo imediatamente, em loop, você pode derrubar ainda mais o sistema que já estava com problema, ou consumir toda a sua cota de requisições em segundos. O padrão que funciona é backoff exponencial: tenta de novo em 1 segundo, se falhar de novo espera 2, depois 4, depois 8, com um limite de tentativas antes de desistir e alertar alguém.

E "alertar alguém" é a parte que mais fica de fora. Uma automação que falha silenciosamente e nunca mais tenta é pior que uma que nunca existiu, porque todo mundo assume que ela está funcionando.

Autenticação entre sistemas: a decisão que ninguém revisita depois

API key fixa é simples de implementar, e é exatamente por isso que ela vaza: aparece em log, em variável de ambiente commitada por engano, em print de tela. OAuth com token de curta duração e refresh automático dá mais trabalho de configurar, mas limita o estrago se vazar, porque o token expira sozinho.

A regra prática que eu sigo: se a integração é entre dois sistemas que eu controlo os dois lados, API key com rotação manual periódica já resolve. Se um dos lados é de terceiro (gateway de pagamento, provedor de e-mail, WhatsApp), prefiro sempre o que o provedor oferecer de mais seguro, mesmo que dê mais trabalho, porque o vazamento ali afeta cliente de verdade, não só o meu ambiente.

Observabilidade: saber que a automação parou antes do cliente perceber

A automação mais perigosa não é a que quebra fazendo barulho, é a que quebra em silêncio. Ela para de rodar numa terça-feira qualquer e ninguém percebe até um cliente reclamar que não recebeu um e-mail, ou que um pagamento não foi processado.

O mínimo que eu considero aceitável em produção: log de toda execução (sucesso e falha, não só falha), e um alerta ativo (e-mail, Telegram, o que for) quando uma automação crítica falha ou fica um tempo sem rodar. Não adianta o log existir se ninguém olha ele até o problema já ter afetado alguém.

Ferramentas que eu recomendo de verdade

n8n self-hosted: pra orquestrar fluxos entre sistemas diferentes sem escrever cola de código pra cada integração nova. A vantagem de rodar self-hosted, em vez do plano cloud, é dado sensível não sair do seu próprio servidor, e não ter limite de execução por plano. O custo é você virar responsável pela manutenção do servidor.

Supabase (Realtime + Edge Functions): quando o sistema de origem e destino já são o seu próprio banco, o Realtime evita polling: qualquer mudança numa tabela dispara evento na hora. Edge Functions são úteis quando a lógica de automação é pequena e não vale a pena subir um serviço separado só pra ela.

Redis como fila: quando o volume justifica, uma fila simples em Redis (com uma lib como BullMQ) resolve o problema de "o webhook precisa responder rápido mas o processamento demora" sem precisar de infraestrutura de mensageria pesada.

Cuidados que custam caro se ignorados

• Nunca chame uma API só pra checar se algo existe antes de decidir o que fazer, se isso puder ser evitado com um retorno de erro tratado. Uma chamada de verificação a mais, multiplicada por milhares de execuções, pode sobrecarregar um serviço que não foi dimensionado pra esse tráfego extra.
• Segredo de API nunca vai em log, nem em modo debug. Sanitizar o payload antes de logar é trabalho extra que compensa na primeira vez que alguém precisa investigar um incidente sem expor credencial no processo.
• Timeout precisa de valor explícito. Uma chamada sem timeout definido pode travar a automação inteira esperando resposta de um sistema que nunca vai responder.

Automação entre sistemas bem feita não aparece: ninguém elogia a automação que nunca falhou. Aparece exatamente quando um desses cuidados foi ignorado.