E se o sistema não tiver API nenhuma?

Ainda dá para integrar, com qualidade menor. As alternativas são leitura direta do banco de dados, importação e exportação de arquivo agendada, ou automação de tela. Todas funcionam, mas quebram mais fácil e exigem monitoramento mais atento do que uma API oficial.

Vale a pena usar uma plataforma pronta de integração?

Vale quando os dois sistemas já têm conector oficial na plataforma e o volume é baixo. A conta muda quando a cobrança é por execução e o fluxo dispara milhares de vezes por dia, ou quando a transformação de dado exige lógica de negócio que a ferramenta visual não expressa bem.

Como evitar que a integração duplique registros?

Com uma chave de correspondência estável e um registro de ligação entre os identificadores dos dois sistemas. Antes de criar qualquer coisa, a integração consulta essa tabela de ligação. Confiar em nome ou e-mail para casar registros é a causa mais frequente de duplicação.

Como integrar dois sistemas que não conversam

Integrar dois sistemas que não conversam começa por um levantamento, não por código: descobrir todas as portas de entrada e saída de cada lado, escolher a direção da sincronia, definir uma chave estável para casar os registros e decidir quem vence quando os dois lados mudam o mesmo dado. Quando esse desenho está claro, a implementação costuma ser a parte curta do projeto.

Passo 1: descubra as portas de cada sistema

Todo sistema tem alguma forma de entrada e saída, mesmo quando o fornecedor diz que não. Faça um inventário honesto dos dois lados:

Porta	Como confirmar se existe
API REST ou SOAP	Documentação pública, ou perguntar ao suporte pelo endpoint e pelo modo de autenticação
Webhook de saída	Procurar em configurações por "notificações", "callback" ou "integrações"
Banco de dados acessível	Perguntar se o banco é local e se existe usuário somente leitura
Exportação agendada	Relatórios que podem ser salvos em CSV ou XML em pasta ou FTP
Importação em lote	Tela de importar planilha, que também serve como porta de entrada
Tela do usuário	Último recurso, via automação de navegador

Vale gastar dias nessa etapa. Descobrir depois que a API é somente leitura, ou que o campo que você precisa não é exposto, muda a arquitetura inteira.

Passo 2: decida a direção e a frequência da sincronia

Existem quatro desenhos comuns, e cada um tem custo diferente:

Padrão	Como funciona	Quando usar
Unidirecional em tempo real	A cria, B recebe via webhook	O dado nasce em um lugar só
Unidirecional em lote	A exporta, B importa a cada X minutos	Sem webhook, volume alto
Bidirecional	Os dois criam e alteram	Só quando é mesmo necessário
Sob demanda	B consulta A na hora que precisa	Dado que muda muito e é lido pouco

A regra prática: evite bidirecional enquanto puder. Sincronia nos dois sentidos multiplica os casos de conflito, exige controle de laço (a alteração que volta e dispara de novo) e é a origem da maior parte dos problemas difíceis de depurar.

Quando bidirecional for inevitável, marque cada alteração com a origem, para que a integração ignore o eco da própria escrita.

Passo 3: escolha a chave de correspondência

Esse é o ponto que define se a integração vai duplicar registros ou não. Você precisa de algo estável que identifique a mesma entidade nos dois lados.

Em ordem de confiabilidade para empresas brasileiras:

CNPJ ou CPF normalizado, sem pontuação, com validação de dígito.
Código interno já compartilhado entre as áreas, quando existe.
Tabela de ligação própria, guardando o id do sistema A e o id do sistema B.

A opção 3 deve existir mesmo quando você usa 1 ou 2. É uma tabela simples com origem, id externo, entidade e data de sincronização. Ela permite responder três perguntas que sempre aparecem: esse registro já foi enviado, qual o id do outro lado, e quando foi a última vez que sincronizou.

Nunca case registros por nome ou por e-mail. Nome tem grafia variável e e-mail é reutilizado entre pessoas.

Passo 4: mapeie os campos e assuma as perdas

Escreva uma tabela de mapeamento antes de programar. Ela vira a documentação da integração e o roteiro de teste.

Campo em A	Campo em B	Transformação	Se vier vazio
razao_social	nome_cliente	corta em 60 caracteres	rejeita
cnpj	documento	remove pontuação	rejeita
uf	estado	sigla maiúscula	usa cadastro padrão
valor_total	vlr_liquido	centavos para decimal	rejeita
forma_pgto	cod_pagamento	tabela de para	usa "outros"

Duas armadilhas frequentes nesse mapeamento: campos com tamanho máximo diferente, que truncam sem avisar, e listas de opções que não batem, exigindo uma tabela de tradução com um valor padrão para o que não existir no destino.

Assuma que alguma informação vai se perder. O importante é decidir conscientemente qual, e não descobrir seis meses depois.

Passo 5: defina quem vence no conflito

Quando o mesmo registro muda dos dois lados, alguém precisa ganhar. As estratégias usadas na prática:

Sistema mestre por entidade. O ERP manda em cadastro fiscal, o CRM manda em contato comercial. Simples e previsível.
Mestre por campo. Mais granular, mais trabalhoso de manter, útil quando as duas áreas realmente editam coisas diferentes do mesmo cadastro.
Última escrita vence. Fácil de implementar e perigoso, porque depende de relógio sincronizado e apaga alteração legítima.
Conflito vira pendência humana. O mais seguro para dado sensível, como limite de crédito ou dado bancário.

Passo 6: construa a camada de integração como um sistema

Uma integração que dura precisa de partes que raramente aparecem no orçamento inicial:

Fila de mensagens. Recebe o evento, responde rápido para quem disparou e processa depois. Evita que o sistema de origem trave esperando.
Idempotência. Uma chave única por evento, gravada antes da ação. Se o mesmo evento chegar duas vezes, o efeito é um só.
Retentativa com espera crescente. Falha de rede é normal. Tentar de novo em 1, 5 e 30 minutos resolve a maioria.
Registro de auditoria. O que entrou, o que saiu, qual resposta veio. Sem isso, cada divergência vira arqueologia.
Painel de pendências. Uma tela com o que falhou, o motivo em linguagem clara e um botão de reprocessar.
Alerta de silêncio. Avisar quando a integração para de receber eventos, que é a falha mais perigosa porque não gera erro.

Erros que aparecem em quase toda integração

Limite de requisições. APIs cortam acima de certo número por minuto. A integração precisa respeitar o limite, e não descobrir isso em produção no fim do mês.
Fuso horário e formato de data. Um lado grava em UTC, outro em horário local. Isso gera relatório com um dia de diferença.
Codificação de caracteres. Arquivo em Latin-1 lido como UTF-8 transforma acento em símbolo estranho e polui o cadastro.
Carga inicial. Sincronizar o histórico é um projeto à parte, com ritmo controlado e conferência por amostragem.
Atualização do fornecedor. Integração por banco direto ou por tela quebra em atualização. Vale contratar aviso prévio quando possível.

Quando parar de integrar e centralizar

Se você já mantém três ou mais integrações ponto a ponto entre os mesmos sistemas, o custo de manutenção cresce mais rápido que o benefício. O padrão nesse ponto é criar um centro: um banco intermediário ou um serviço que concentra o cadastro mestre, com cada sistema conversando só com ele.

Isso reduz o número de ligações de N vezes N para N, e dá um lugar único para consultar quando alguém pergunta qual é o dado correto. É também o passo natural antes de construir um painel que junte informação de várias origens.