Integração de sistemas: como tirar o trabalho manual
Entenda o que é integração de sistemas, quais caminhos existem e o que precisa estar definido — e validado — antes de colocar em produção.
O que é integração de sistemas — e o sinal de que a operação precisa
Integração de sistemas é fazer dois ou mais softwares trocarem dados sozinhos, sem ninguém copiar informação de uma tela para outra. A troca acontece por uma conexão programada — API, webhook, arquivo ou banco de dados — com regras combinadas: o que sai, para onde vai, o que fazer quando algo falha.
O sinal aparece antes de qualquer projeto: alguém exporta um relatório de um sistema e importa no outro, o mesmo cadastro é digitado duas vezes, o número do pedido que existe no sistema de vendas não existe no de faturamento.
Se o dado precisa passar por uma pessoa para chegar ao outro lado, ainda não existe integração — existe trabalho manual com aparência de processo. E integrar não é trocar de sistema: na maior parte dos casos as ferramentas atuais continuam onde estão, e o trabalho é fazer a informação circular entre elas.
Os três caminhos: nativo, plataforma e sob medida
A escolha do caminho depende de duas perguntas: quantos sistemas estão envolvidos e quanta regra própria existe no meio do fluxo.
| Caminho | Quando serve | O que exige | Onde dói |
|---|---|---|---|
| Conexão nativa (API ou webhook do fornecedor) | Fluxo direto entre dois sistemas que já oferecem interface programável | Credencial com escopo mínimo e alguém responsável por manter a conexão | Fornecedor sem API, limite de chamadas e mudança de versão que quebra o que funcionava |
| Plataforma de integração | Vários sistemas, conectores prontos e pouca regra específica | Assinatura, configuração e conhecimento da ferramenta | Regra particular que a plataforma não expressa; dado sensível passando por terceiro |
| Desenvolvimento sob medida | Regra própria, cálculo, exceção, vários destinos ou sistema legado sem API | Especificação, desenvolvimento, teste e manutenção | Investimento inicial maior e dependência de quem construiu, reduzida com documentação |
Nenhum dos três é o caminho “certo” em abstrato: a conexão nativa fica frágil quando a regra cresce, a plataforma cobra configuração em cada conector e o desenvolvimento sob medida é o que sobra quando a regra é sua.

O que precisa estar definido antes de desenvolver
Antes de escrever a primeira linha, a integração precisa de seis definições: origem, destino, chave única do registro, regra, exceção e o que fazer quando a entrega falha. Sem elas, o desenvolvimento vira tentativa e erro em cima de dados reais da operação.
- Origem e gatilho. Qual evento dispara a troca: registro novo, alteração de campo ou horário agendado. Gatilho mal definido é a causa mais comum de dado que sai duas vezes.
- Destino e chave única. Onde o dado é gravado e qual campo identifica aquele registro nos dois lados. Sem chave única, a segunda execução cria uma linha duplicada em vez de atualizar a existente.
- Regra e exceção. O que é transformado no caminho (data, unidade, tabela de códigos) e o que acontece quando o registro não passa na validação: fica retido, entra como pendência ou é descartado com registro.
- Retentativa e idempotência. Repetir uma operação precisa ser seguro. A documentação da Stripe sobre requisições idempotentes descreve o mecanismo: uma chave única por operação faz a segunda tentativa devolver o resultado da primeira em vez de executar tudo de novo.
- Fila e tempo de resposta. Se a entrega acontece por webhook, quem recebe precisa responder rápido e processar depois. O guia de boas práticas para webhooks do GitHub orienta responder em até 10 segundos com status 2XX e usar uma fila para o processamento em segundo plano — acima disso, a entrega é considerada falha.
- Registro e alerta. Cada execução precisa deixar rastro: o que entrou, o que saiu, o que foi rejeitado e por quê.
Quando a entrega se repete ou falha no meio
Entrega repetida, falha parcial e tempo esgotado são esperados, não exceção. A integração bem construída trata os três: reconhece o que já processou, sabe onde parou e compara os dois lados depois.

A duplicidade acontece porque o mesmo evento pode ser entregue mais de uma vez, inclusive em reenvio manual: o GitHub registra que o identificador da entrega se repete quando ela é reenviada, e quem recebe precisa descartar o que já processou.
A falha parcial é o caso mais caro: o pedido foi gravado no destino, mas a confirmação não voltou. Reprocessar sem critério duplica; ignorar deixa o dado inconsistente — o caminho é consultar o destino pela chave única antes de decidir. Já o tempo esgotado pede fila com nova tentativa em intervalo crescente e limite de tentativas; passado o limite, o item vira pendência com responsável.
Por fim, a conciliação: comparar periodicamente a quantidade e o valor dos registros nos dois lados. É o único teste que mostra se a integração está completa, e não apenas funcionando sem erro visível.
Segurança e dados pessoais: o que a LGPD cobra da integração
Se a integração transporta dado pessoal, quem decide o tratamento responde por ele. A Lei 13.709/2018 (LGPD) determina no art. 46 que os agentes de tratamento adotem medidas técnicas e administrativas para proteger dados pessoais de acessos não autorizados e de tratamento inadequado, e no art. 48 que o controlador comunique à autoridade e ao titular o incidente de segurança que possa acarretar risco ou dano relevante.
Na prática, isso muda o projeto em quatro pontos: credencial com o menor escopo possível, segredo de webhook para validar a origem da chamada, conexão HTTPS e registro de acesso. O guia do GitHub recomenda ainda inscrever-se no número mínimo de eventos e não colocar credencial na URL que recebe o payload.
Vale distinguir os papéis, como faz a página de perguntas frequentes da ANPD: o controlador decide sobre o tratamento, o operador realiza o tratamento em nome dele e o encarregado é o canal com titulares e autoridade — com dispensa prevista para agentes de pequeno porte. Quem integra costuma atuar como operador, e isso precisa estar claro no contrato.
Como validar antes de colocar em produção
Validar é rodar a integração com dado real, em ambiente controlado, antes de deixá-la operando sozinha. Cinco verificações cobrem o essencial:
- Piloto com dado real de um período fechado, não com registro fictício.
- Execução em paralelo com o processo manual por alguns ciclos, comparando os dois resultados.
- Conciliação de totais por período: quantidade e valor precisam fechar dos dois lados.
- Simulação de falha — destino fora do ar, credencial inválida, registro incompleto — para ver se o alerta chega e se o reprocessamento funciona.
- Responsável definido pelo acompanhamento depois do go-live, com prazo para a primeira revisão de conciliação.

Integração sem dono vira problema de ninguém: quando os números divergem, ninguém sabe dizer se o erro está na origem, na regra ou no destino.
Pronto, plataforma ou sob medida: como decidir
Comece pelo mais simples que resolva o fluxo inteiro. Dois sistemas com interface programável e regra curta pedem conexão nativa; vários sistemas com conectores prontos pedem plataforma.
O desenvolvimento sob medida entra quando a regra é sua: cálculo que depende da operação, exceção que muda por contrato, sistema legado sem API ou vários destinos com formatos diferentes. É o cenário descrito em quando o sistema sob medida é o caminho e o que aparece em um CRM sob medida que recebe dados de site, telefone e campanha.
Se o gargalo é o sistema em si, e não a conexão, o caminho é sistemas e aplicativos sob medida — a avaliação começa pelos fluxos que hoje dependem de redigitação.
Perguntas frequentes
O que é integração de sistemas?
É a conexão programada entre dois ou mais softwares para que troquem dados sem intervenção manual. Um evento em um sistema dispara uma chamada que grava ou atualiza a informação no outro, seguindo regras de origem, destino, validação e tratamento de falha.
Quais são os tipos de integração de sistemas?
As divisões mais usadas separam pelo que é integrado — dados, aplicações, sistemas legados — e pelo método: API ou webhook, plataforma de integração, arquivo ou banco de dados. O tipo descreve o caminho; a decisão depende da regra de negócio e do número de sistemas.
Dá para integrar sistemas antigos sem trocá-los?
Na maioria dos casos, sim. Quando o sistema antigo não oferece API, a conexão pode ser feita por banco de dados, arquivo em intervalo programado ou uma camada intermediária que expõe os dados de que a outra ponta precisa. O limite é o fornecedor que não permite nenhum acesso programático: aí a troca vira decisão de negócio.
Como saber se a integração está funcionando depois de entrar no ar?
Três sinais: os registros aparecem dos dois lados na mesma quantidade, a conciliação de totais fecha por período e os alertas de falha chegam a alguém que sabe agir. Olhar o “sem erro” no painel não basta — é a comparação entre os dois lados que mostra se algum dado ficou pelo caminho.
Quem responde pelos dados pessoais que passam entre os sistemas?
Quem decide sobre o tratamento responde pela finalidade e pela segurança dele; quem executa a integração em nome dessa empresa atua como operador. A LGPD exige medidas de segurança no art. 46 e comunicação de incidente relevante no art. 48, e o papel de cada parte deve estar descrito no contrato.
O próximo passo
Integração de sistemas não começa no código: começa na lista dos fluxos que hoje dependem de alguém copiando dado de uma tela para outra. Com essa lista em mãos, dá para decidir o que resolver primeiro.
Se o caminho for automatizar também as etapas seguintes — aviso, cobrança, atendimento — vale conhecer o agente de IA para WhatsApp que opera em cima do dado já integrado. E, se a integração exigir regra própria ou sistema novo, a conversa começa com uma avaliação dos seus fluxos: Quero criar ou evoluir um sistema.