API ou EDI: como trocar dados com clientes e parceiros

EDI (troca eletrônica de dados) é um conjunto de padrões para empresas trocarem documentos de negócio — pedidos, avisos de embarque, notas, status — em formatos rígidos e acordados. Em vez de conversa em tempo real, há troca de arquivos, muitas vezes em lotes e por canais dedicados.

Quando usar API

API é a escolha natural quando:

• Os dois sistemas precisam de informação em tempo real (estoque, preço, status).
• Os dois lados conseguem desenvolver e manter a integração.
• Você quer oferecer um canal próprio para clientes e parceiros se conectarem.

Uma boa API tem autenticação, documentação (Swagger/OpenAPI), versionamento e limites de uso. Sem isso, ela vira uma porta aberta difícil de manter. Em .NET, o ASP.NET Core facilita bastante esse trabalho.

Quando usar EDI

EDI faz sentido quando:

• Um grande parceiro exige o padrão — comum em operadores logísticos, varejo e indústria.
• O volume é alto e o processamento em lote é aceitável.
• Vários participantes precisam falar a mesma "língua" de documentos.

Quando desenvolvi uma plataforma EDI para a UPS, o desafio não era só ler arquivos: era validar, converter e conciliar grandes volumes todos os dias, garantindo que nenhum registro se perdesse no caminho.

O que deixa uma integração frágil

A maior parte dos problemas não vem da escolha entre API e EDI, mas da falta de cuidado com o que acontece quando algo dá errado:

1. Sem logs: ninguém sabe o que foi enviado, recebido ou rejeitado.
2. Sem validação: dados ruins entram no sistema e só aparecem no fim do mês.
3. Sem reprocessamento: quando o parceiro fica fora do ar, os dados daquele período se perdem.
4. Sem alerta: a integração para numa sexta-feira e alguém descobre na segunda.

Toda integração que eu desenvolvo registra cada troca, valida os campos, permite reprocessar e avisa quando falha. Isso custa pouco no início e economiza muito depois. Veja mais em APIs e integrações.

Um exemplo concreto

Imagine uma transportadora que recebe pedidos de três embarcadores. O maior envia arquivos EDI; os outros dois mandam planilhas por e-mail. Um desenho possível:

• Conector EDI para o embarcador maior, com validação e conciliação diária.
• API REST simples para os outros dois enviarem pedidos direto do sistema deles.
• Um painel com o status de cada troca e alertas de falha.

O resultado é o fim da digitação manual e uma fonte única de verdade para os pedidos — algo que um sistema de gestão de transporte aproveita muito bem.

Segurança e responsabilidade nas trocas

Integração também é uma questão de segurança. Algumas práticas que considero obrigatórias:

• Credenciais por parceiro: cada cliente ou parceiro tem a sua chave de API ou o seu certificado. Se um vazar, você revoga só aquele acesso.
• HTTPS sempre e, no EDI, canais seguros como SFTP ou AS2.
• Limites de uso para que um parceiro com problema não derrube o sistema de todos.
• Registro de quem enviou o quê e quando, o que ajuda tanto na auditoria quanto em discussões comerciais sobre um pedido que "nunca chegou".

Esses cuidados também facilitam o atendimento à LGPD, porque deixam claro que dados pessoais circulam, para quem e com que finalidade.

Por onde começar

Liste quais dados entram e saem da sua empresa, com que frequência e em que formato. Marque onde há digitação manual ou retrabalho. Esse mapa, por si só, já mostra qual integração traz mais retorno — e é o primeiro passo de qualquer projeto sério de integração.