# Integração de sistemas: API, webhook, fila ou arquivo? Guia para gestores

> Integração de sistemas explicada para gestores: quando usar API, webhook, fila ou arquivo e os cinco princípios que evitam pedidos perdidos.

- URL: https://trustsoftlabs.com/blog/integracao-de-sistemas-api-webhook-fila
- Publicado: 2026-08-25 · Atualizado: 2026-09-22
- Autor: Equipe TrustSoft (TrustSoft, Belo Horizonte/MG)
- Categoria: Integrações · Tags: integração de sistemas, API, webhook, mensageria, ERP

> **Em resumo:** a integração de sistemas pode ser feita por API (consulta sob demanda), webhook (aviso de evento), fila de mensagens (entrega garantida) ou troca de arquivos (lote). Boas integrações combinam essas técnicas e seguem cinco princípios: idempotência, retentativa, fila de exceções, contrato documentado e monitoramento. Sem eles, uma falha do outro lado vira pedido perdido.

Fazer **integração de sistemas** parece simples ("é só ligar um no outro"), até o primeiro pedido duplicado ou perdido. A boa notícia é que existem padrões consolidados para fazer isso com segurança. Este guia explica cada um em linguagem de gestão, para você conduzir a conversa com fornecedores e avaliar propostas.

## As quatro formas mais comuns de integração de sistemas

### 1. API (consulta sob demanda)

Um sistema **pergunta** ou **envia** dados a outro por meio de uma interface definida, geralmente REST. É como um garçom: você faz o pedido e recebe a resposta na hora. Se a sigla ainda é nova para você, veja [O que é API](/blog/o-que-e-api).

**Bom para:** consultar preço, estoque ou status em tempo real; criar um pedido; fluxos em que o usuário espera a resposta.
**Atenção:** se a API do outro lado estiver fora do ar, a operação falha na hora. É preciso prever repetição e tratamento de erro.

### 2. Webhook (aviso de evento)

O sistema de origem **avisa** o de destino quando algo acontece: "pagamento confirmado", "pedido criado". Em vez de ficar perguntando, você é notificado.

**Bom para:** confirmação de pagamento, mudança de status, eventos de marketplaces.
**Atenção:** avisos podem chegar duplicados, fora de ordem ou simplesmente não chegar. O receptor precisa ser **idempotente** (processar o mesmo aviso duas vezes sem efeito duplicado) e conferir periodicamente o que ficou pendente.

### 3. Filas de mensagens (mensageria)

Em vez de um sistema chamar o outro diretamente, as mensagens passam por uma **fila** que as guarda até o destino processar. É um correio confiável entre os sistemas.

**Bom para:** volume alto, sistemas que ficam fora do ar às vezes, picos de demanda e processamento em segundo plano.
**Atenção:** exige monitoramento da fila e uma **fila de exceções** para mensagens que falharam repetidamente.

### 4. Troca de arquivos (CSV, XML, SFTP)

Um sistema gera um arquivo em horários definidos, e o outro o consome. É antigo, mas ainda comum em bancos, contabilidade e sistemas legados.

**Bom para:** integrações em lote e sistemas sem API.
**Atenção:** dados desatualizados entre as execuções e formatos frágeis, em que uma coluna a mais quebra tudo. Valide o arquivo antes de processar.

![Switch de rede com várias portas ethernet](https://3o30xiktvpxbncix.public.blob.vercel-storage.com/blog/integracao-de-sistemas-api-webhook-fila-inline-bdaef484.webp)

*autor desconhecido (domínio público, via rawpixel).*

## Como escolher

| Necessidade | Escolha típica |
|---|---|
| Resposta imediata para o usuário | API |
| Ser avisado de um evento externo | Webhook, com conferência periódica |
| Alto volume ou sistemas instáveis | Fila de mensagens |
| Sistema legado sem API | Arquivo, acesso controlado ao banco ou automação de tela (RPA) |

Na prática, boas integrações **combinam** técnicas: recebem o evento por webhook, colocam em fila, processam com retentativa e consultam a API para conferir o resultado.

## Os cinco princípios que evitam pedido perdido

1. **Idempotência:** processar a mesma mensagem duas vezes não pode duplicar o pedido nem a cobrança. Cada operação carrega um identificador único. A [documentação da Stripe sobre requisições idempotentes](https://docs.stripe.com/api/idempotent_requests) é um bom exemplo de como grandes plataformas de pagamento resolvem isso com uma chave enviada em cada requisição.
2. **Retentativa com espera crescente:** falhas temporárias são tentadas de novo automaticamente, com intervalos cada vez maiores, para não sobrecarregar um sistema que já está com problema.
3. **Fila de exceções:** o que não conseguiu ser processado depois de algumas tentativas vai para uma fila separada, visível e com alerta, e pode ser reprocessado. A AWS descreve esse padrão como [dead-letter queue](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html) no seu serviço de filas.
4. **Contrato documentado:** campos, formatos e regras de cada troca ficam escritos, por exemplo na [especificação OpenAPI](https://www.openapis.org/), e mudanças são versionadas.
5. **Monitoramento:** um painel mostra o que entrou, o que falhou e quanto tempo levou, e alguém é avisado quando algo foge do normal.

## E o sistema legado sem documentação?

A recomendação costuma ser uma **camada de adaptação**: um componente que conversa com o legado do jeito que ele aceita (banco, arquivo ou tela) e expõe uma interface moderna para o resto da empresa. Assim, o legado fica isolado, e novos sistemas se integram sem depender das suas peculiaridades. Essa camada também permite substituir o legado por partes no futuro, a estratégia que Martin Fowler batizou de [Strangler Fig](https://martinfowler.com/bliki/StranglerFigApplication.html): o sistema novo cresce ao redor do antigo até que ele possa ser desligado.

## Perguntas para fazer ao fornecedor

- O que acontece com um pedido se o sistema de destino ficar fora do ar por duas horas?
- Como vocês garantem que a mesma mensagem não será processada duas vezes?
- Onde eu vejo as falhas e como reprocesso?
- A integração está documentada e versionada?
- Quem é avisado, e em quanto tempo, quando algo quebra?

Se as respostas forem vagas, a integração provavelmente vai quebrar em silêncio.

## Como a TrustSoft conduz integrações

Começamos mapeando quais sistemas trocam dados, o que cada um oferece e onde hoje há digitação manual. Depois desenhamos contratos, tratamento de falhas e monitoramento, entregando em ciclos de 1 a 2 semanas. Veja como fazemos [integração de sistemas e APIs](/solucoes/integracao-de-sistemas-apis) e, quando o legado é o gargalo, [modernização de sistemas](/solucoes/modernizacao-de-sistemas).

## Perguntas frequentes

### Qual a diferença entre API e webhook?

Na API, o seu sistema pergunta quando precisa da informação. No webhook, o outro sistema avisa o seu quando algo acontece. Muitas integrações usam os dois: o webhook avisa e a API confirma os detalhes.

### Integração em tempo real é sempre melhor?

Não. Tempo real faz sentido para estoque, pagamento e status de pedido. Para relatórios, conciliações e cargas grandes, processamento em lote costuma ser mais simples, barato e confiável.

### Dá para integrar um sistema que não tem API?

Na maioria dos casos, sim, por troca de arquivos, acesso controlado ao banco de dados ou robôs que operam a tela (RPA). Cada caminho tem custos e riscos diferentes, que devem ser avaliados caso a caso.

### Quanto tempo leva uma integração?

Depende da qualidade da API do outro lado e das regras de negócio envolvidas. Uma integração ponto a ponto costuma levar algumas semanas; um hub que conecta vários sistemas é entregue em fases.

Quer avaliar a integração dos seus sistemas? [Converse com a gente](/#contato).

**Imagens:** capa: ["Free networking cables image", autor desconhecido (domínio público, via rawpixel)](https://www.rawpixel.com/image/5919227/image-background-public-domain-technology); imagem 1: [autor desconhecido (domínio público, via rawpixel)](https://www.rawpixel.com/image/6048740/free-public-domain-cc0-photo).

---
Fonte: TrustSoft — https://trustsoftlabs.com/blog/integracao-de-sistemas-api-webhook-fila