Engenharia de Automações para CRM e WhatsApp
Ferramentas em Python que auditam e alteram com segurança centenas de fluxos de automação de vendas em um CRM — e os links de convite assinados e com prazo que conectam essas automações de WhatsApp a uma área de membros.
- Cliente
- Agência de marketing digital (nome omitido)
- Papel
- Ferramentas, migrações e desenho de integrações
- Ano
- 2026
- Status
- Em uso nos fluxos de produção
≈400
fluxos de produção auditados pela API
247
fluxos migrados com backup e reversão
109
scripts embutidos corrigidos por erro de fuso
32 → 0
blocos sobrepostos após o layout automático
Contexto
As vendas da agência rodam em funis de WhatsApp montados como centenas de fluxos dentro de um CRM. Alterá-los à mão era lento e arriscado, e uma migração de API do fornecedor estava prestes a quebrar parte deles.
O problema
Fazer grandes mudanças em automações de produção com segurança, encontrar o que vai quebrar antes que quebre e conectar o CRM aos sites da própria agência sem gambiarras frágeis.
O que eu fiz
- 01
Escrevi ferramentas em Python sobre a API REST do CRM com um único padrão para toda mudança: simulação → backup → aplicação → releitura e comparação → reversão com um comando.
- 02
Projetei links de convite assinados com HMAC e com prazo, compartilhados entre as automações do CRM e uma área de membros em Next.js.
- 03
Especifiquei um redesenho do webhook de leads da plataforma, seguro contra rate limit, depois de uma rajada de erros 429.
O que faz
- Campos de data e hora migrados para campos de data filtráveis em 247 fluxos
- Levantamento de todos os fluxos que ainda chamavam rotas da API do fornecedor prestes a ser desligadas
- Layout automático dos diagramas de fluxo com prévias em SVG de antes e depois
- Clonagem de ramos para incluir um novo produto em um funil de WhatsApp de várias etapas
Destaques de engenharia
- 01
Gestão de mudanças para automações
Toda alteração em lote roda primeiro em simulação, faz backup de cada fluxo, aplica pela API, relê para comparar e vem com um script de reversão.
- 02
Um bug de fuso em escala
Scripts dentro do CRM rodavam em UTC e gravavam o dia seguinte entre 21h e meia-noite no horário local. 109 blocos de script em 63 fluxos passaram a usar America/Sao_Paulo.
- 03
Layout de grafos para diagramas de fluxo
Colunas pelo caminho mais longo, faixas por seção e verificação de sobreposição reorganizam fluxos embaralhados: os blocos sobrepostos caíram de 32 para 0 nos maiores.
- 04
Links de convite com teste de contrato
Links HMAC-SHA256 de 8 horas com comparação em tempo constante, verificados no proxy do Next.js. Um harness executa o bloco JavaScript real do CRM contra as regras do site: 19 casos em 3 fluxos.
Partes difíceis
- 01
O desligamento de uma API
Um levantamento somente leitura encontrou 47 fluxos e 71 blocos ainda chamando rotas descontinuadas antes de os servidores antigos serem desligados.
- 02
Limites compartilhados
O CRM permite 60 requisições por minuto por rota em um único contador. O redesenho do webhook usa uma fila persistente com debounce, orçamento de ~40/min e respeito ao Retry-After.
Resultados
- Expiração dos links de convite verificada em produção com uma matriz de testes: links vencidos, válidos, vitalícios, adulterados e incompletos.
- Toda mudança nos fluxos de produção pode ser revertida com um comando.
Os números vêm do repositório: testes, medições e relatórios documentados.
Stack
- Python
- JavaScript
- TypeScript
- REST APIs
- Webhooks
- HMAC-SHA256
- Next.js
ProcessoConstruído com assistência de IA sob minha direção; toda mudança segue a mesma disciplina de simulação, verificação e reversão.
Código e cliente são privados. Os detalhes são compartilhados até onde o trabalho permite.