Integrações de aplicativos: como os softwares conversam entre si

Integrar aplicativos não começa no código. Começa no desenho do fluxo.

Você abre o CRM e o cliente está duplicado. O pedido saiu na loja, mas o financeiro não viu. O frete foi calculado com uma tabela velha porque a transportadora não conversa com o carrinho. Tudo isso parece problema de sistema quebrado, mas a raiz é outra.

Falta um combinado entre os softwares. E esse combinado não exige virar programador. Exige entender qual peça encaixa no seu volume, na sua equipe e na sua tolerância a erro.

Eu sempre começo perguntando qual dado não pode falhar; a ferramenta vem depois.

• Integração de aplicativos é a troca de dados e o disparo de ações entre dois ou mais softwares sem intervenção humana.
• Uma integração moderna se divide em camadas de transporte, contrato, autenticação, evento, dados e orquestração.
• As rotas práticas são integração nativa de marketplace, automação low-code, iPaaS gerenciado e desenvolvimento customizado sobre API pública.
• Webhook é o sistema que avisa quando um evento acontece; API é o sistema que responde quando perguntado.
• Falhas comuns em produção incluem retry sem backoff exponencial, ausência de idempotência e contrato quebrado sem monitoramento.

• O mapa das cinco camadas que sustentam qualquer troca de dados entre aplicativos.
• Comparação direta entre API, webhook, iPaaS e arquivo com critérios de volume, controle e manutenção.
• O que pode quebrar quando o fornecedor muda o contrato ou o pedido chega duplicado.
• Será que a integração pronta do marketplace resolve o seu caso ou esconde um limite que só aparece no pico?

O que está por trás da tela quando dois sistemas conversam

Muita gente vê uma integração como um plugue que encaixa em outro plugue. A realidade é mais parecida com um encanamento: cada camada precisa suportar pressão, vedar vazamento e indicar onde a água parou.

Quando o pedido entra no e-commerce e não aparece no ERP, o defeito pode estar no contrato, na autenticação ou no monitoramento. Sem saber qual camada falhou, você troca de ferramenta e o problema continua.

Antes de conectar, defina qual sistema é a fonte da verdade para cada dado. Quem pode atrasar, quem pode duplicar e quem precisa ser notificado em tempo real. Esse desenho evita retrabalho de mapeamento.

Integração de aplicativos: o encanamento invisível que sustenta a operação

Integração de aplicativos é o conjunto de meios pelos quais dois ou mais softwares trocam dados e disparam ações sem intervenção humana. Não é um produto, é uma decisão de arquitetura.

Ela existe porque nenhum sistema cobre todas as etapas do negócio. Um e-commerce não emite nota. Um CRM não calcula frete. A integração preenche esse vão.

O que separa uma integração de uma exportação de planilha

A planilha é um retrato tirado em um momento. A integração é um fluxo contínuo. Exportar CSV e importar no ERP mantém os dois lados vivos, mas exige um humano no meio.

Uma integração automatizada elimina a redigitação, reduz divergência de cadastro e deixa a operação reagir a eventos em segundos.

O ponto central é o contrato: um formato combinado de campos, tipos e regras. Sem contrato, cada lado interpreta o dado de um jeito.

Por que a empresa média já tem cinco sistemas que não se falam

CRM, ERP, emissor de nota, plataforma de e-commerce e canais de mensageria. Essa pilha é comum em operações brasileiras pequenas e médias.

Cada software resolve uma dor isolada. Mas quem cadastra o cliente no CRM precisa do pedido no ERP e da conversa no WhatsApp. Sem integração, a informação mora em ilhas.

Foi assim que nasceu o marketplace de aplicativos: catálogos de integrações prontas que evitam construir tudo do zero. O ecossistema da HubSpot reúne mais de 2.300 apps publicados, e plataformas brasileiras como Machine, Tray, Frenet, Blip e Olist mantêm catálogos próprios.

Como funciona por dentro: as cinco camadas de uma integração

Ver essa foto no Instagram

Por baixo do botão de conectar existe uma pilha de responsabilidades. Cada camada resolve uma pergunta específica.

Eu gosto de começar por aqui porque a maioria dos erros que já vi em produção nasce de uma camada ignorada.

• Transporte: como os bytes viajam com segurança. Em integrações modernas, sempre HTTPS com TLS.
• Contrato: o formato da mensagem. REST, GraphQL, gRPC ou SOAP definem o vocabulário.
• Autenticação: quem pode falar com quem. OAuth 2.0, chave de API, JWT ou mTLS.
• Evento: como um sistema descobre que algo mudou. Webhook, polling ou fila.
• Dados: como os campos do sistema A viram os campos do sistema B, com normalização e deduplicação.
• Orquestração: a ordem das tarefas e quem cuida das falhas.

Essas camadas não são opcionais. Uma integração que ignora uma delas funciona no teste e quebra na produção.

Contrato: REST, GraphQL, gRPC e SOAP na prática

O contrato define os endpoints, o schema e a versão. REST é o mais comum: recursos expostos via HTTP e JSON. GraphQL permite pedir exatamente os campos necessários, evitando payloads inchados.

gRPC usa HTTP/2 e Protobuf para alta performance entre serviços internos. SOAP é o legado formal, com WSDL e XML, ainda vivo em ERPs antigos e grandes varejistas.

OpenAPI é o padrão para descrever contratos REST. Documentação gerada a partir do OpenAPI permite testar a API sem escrever código.

Autenticação: OAuth 2.0, chave de API, JWT e mTLS

Autenticação responde quem pode ler e escrever. OAuth 2.0 é o padrão para delegação de acesso, conforme RFC 6749. Ele permite que um aplicativo aja em nome do usuário sem ver a senha.

Chave de API é simples, mas frágil: quem captura a chave ganha acesso. JWT é um token assinado com claims e validade curta, conforme RFC 7519. mTLS é autenticação mútua por certificado, comum em ambiente financeiro.

A escolha errada expõe dado pessoal. Com a LGPD, qualquer sincronização que envolva dado de cliente precisa de trilha de auditoria e consentimento registrado.

Evento: webhook, fila e event stream

Existem dois modelos de descoberta: polling e push. Polling pergunta de tempos em tempos. Webhook é push: o sistema de origem chama uma URL cadastrada quando o evento acontece.

Um webhook com assinatura HMAC prova que a mensagem veio do remetente certo e não foi adulterada. Sem assinatura, qualquer um pode injetar payload falso.

Event stream é uma evolução: em vez de um chamado por evento, um stream contínuo como um log de mudanças. Permite reprocessar, auditar e escalar.

Na prática, um lead que chega no formulário aciona um webhook para o CRM em segundos. O cuidado é que o webhook depende de URL pública e de o consumidor estar de pé; se estiver fora do ar, o evento se perde.

Dados: mapeamento de campos, normalização e deduplicação

O campo CLIENTE_ID no A pode ser CUSTOMER_ID no B. Sem mapeamento explícito, o dado morre na fronteira.

Normalização padroniza datas, telefones e moedas. Deduplicação usa uma chave natural, como e-mail ou CPF, para não criar dois registros do mesmo cliente.

A sincronização bidirecional é a mais arriscada. Se os dois lados podem editar, alguém precisa vencer o conflito. Defina a fonte da verdade antes de ligar o fluxo.

Orquestração: quem dispara o quê e em que ordem

Orquestração é a sequência de passos de uma jornada. Exemplo: cliente fecha pedido no e-commerce. O sistema dispara um evento. A orquestração chama a API de frete, depois o ERP, depois envia o comprovante.

Plataformas de automação low-code e iPaaS ocupam esse espaço. Elas desenham o fluxo visualmente e cuidam de retry, fila e log.

Os tipos de conexão comparados: API, webhook, iPaaS e arquivo

Cada rota resolve um contexto. A tabela abaixo sintetiza o trade-off.

API REST e GraphQL: controle total, trabalho proporcional

Integrar sobre a API pública dá acesso a todos os campos e permite mapear regras específicas. Em troca, você escreve código, cuida de autenticação, rate limit, versionamento e monitoramento.

iPaaS e automação low-code: Zapier, Make e n8n

Essas plataformas entregam orquestração visual com centenas de conectores prontos. Zapier e Make são SaaS com planos baseados em tarefas. n8n é open source e pode rodar na sua infraestrutura.

O ganho está na velocidade de entrega. A limitação está na profundidade do mapeamento e na dificuldade de depurar quando o fluxo cresce.

Para times sem desenvolvedor, o iPaaS costuma ser o caminho com menor custo de manutenção.

Arquivo, EDI e planilha: o que ainda funciona e por quê

Trocar CSV por FTP ou pasta monitorada continua vivo em ERPs antigos. EDI é o padrão de documentos com grandes varejistas. A planilha compartilhada é o elo mais frágil, mas resiste porque todo mundo sabe abrir.

O custo oculto é o retrabalho: alguém digita de novo, o dado envelhece, a auditoria vira caça ao erro.

Integração nativa do marketplace ou integração sobre API pública?

O marketplace de aplicativos entrega atalho. Instalar uma integração pronta pode resolver em uma tarde. A HubSpot tem mais de 2.300 apps publicados, com conectores como Gmail acumulando cerca de 527 mil instalações.

Mas a integração pronta encapsula a lógica do fornecedor. Você não vê o mapeamento, não ajusta o retry, não tem diagnóstico fino.

Quando a integração pronta resolve em uma tarde

Use quando o fluxo é padrão, o volume é baixo e você aceita as regras do fornecedor. Exemplo: sincronizar contatos do formulário para o CRM ou puxar frete de transportadora parceira.

O preço da conveniência: menos controle, menos diagnóstico

Quando algo falha, o log do conector costuma ser genérico. Você não sabe se o problema foi no token, no rate limit ou no payload. Para operação crítica, isso se torna um risco.

Os limites técnicos que definem o que a integração aguenta

Antes de escolher a rota, olhe para os números da sua operação. Volume diário, pico de vendas e tolerância a atraso definem a arquitetura.

Rate limit: o teto invisível de requisições por minuto

Toda API pública impõe um teto de chamadas. Estourar o limite gera erro 429 e fila. Sem backoff exponencial, o retry imediato repete o erro e agrava a fila.

Teste o rate limit antes do go-live. Simule pico de 2x o volume normal.

Latência, volume e o custo de sincronizar em dois sentidos

Sincronização bidirecional dobra a chance de conflito. Se o CRM e o ERP podem editar o mesmo cliente, você precisa de timestamp e regra de vitória.

Volume alto com latência baixa pede event stream ou fila. Volume baixo aceita polling de minutos.

Versionamento de API: quando o fornecedor muda o contrato

APIs mudam. Campo renomeado, endpoint descontinuado, autenticação migrada. Sem testes de contrato e monitoramento de erro, a integração quebra silenciosamente.

Exija que o fornecedor versiona a API e publique changelog. Se não publica, trate como risco.

Como escolher a abordagem certa para o seu contexto

Quatro eixos resolvem a decisão: volume de operações por dia, criticidade do dado, existência de equipe técnica própria e velocidade de mudança no negócio.

Comece pelo volume e pela tolerância a atraso

Menos de mil eventos por dia e atraso de minutos aceitável? Integração nativa ou low-code resolvem. Volume de dezenas de milhares com latência de segundos? Você precisa de desenvolvimento customizado ou iPaaS gerenciado.

Quanto de controle você realmente precisa ter

Se uma falha custa venda ou multa, você precisa de logs, retry customizado e monitoramento ativo. A integração pronta não entrega isso.

Quem vai manter isso daqui a um ano

Integração não termina no go-live. Sem uma pessoa responsável por olhar falhas, a automação vira dívida técnica.

Dúvidas que travam o projeto antes de ele começar

Algumas objeções são legítimas. Outras são mito.

Preciso saber programar para integrar?

Não. Low-code e conectores nativos resolvem a maioria dos casos. Saber ler JSON e entender autenticação ajuda, mas não é barreira.

Minha empresa é pequena, planilha não resolve?

Planilha resolve até o primeiro erro de digitação que vira nota fiscal errada. O custo de retrabalho costuma superar o esforço de montar uma automação simples.

Se eu trocar de fornecedor, perco a integração?

Se a integração foi construída sobre API pública e com contrato documentado, trocar o sistema de destino é mais simples. Integração pronta amarra você ao marketplace.

Eu já vi integração morrer na reunião de escopo porque ninguém respondeu qual sistema era o dono do cadastro do cliente. Não é sobre a API. É sobre a regra de negócio. Muita gente pergunta qual ferramenta usar, mas pouca gente pergunta o que fazer quando o pedido chegar duplicado. A resposta define se a automação sobrevive ao primeiro pico de vendas. Aprendi a desconfiar de demo bonita: integração se prova em produção, não no teste feliz. O caminho seguro é desenhar o fluxo de erro antes de desenhar o fluxo de sucesso.

Por isso, antes de mais nada, defina a regra de idempotência: a mesma mensagem processada duas vezes precisa gerar o mesmo resultado que uma vez.

Idempotência, retry com backoff e dead letter queue: engenharia de falha

O pior pesadelo de uma integração não é o erro. É o erro que se repete sozinho e multiplica pedidos.

Por que o pedido duplicado nasce do timeout, não do usuário

Um timeout acontece quando a resposta demora e o cliente desiste. O servidor pode ter processado a requisição mesmo assim. Se o cliente tentar de novo, o pedido entra duas vezes.

Sem idempotência, a rede instável vira duplicidade no ERP e cliente cobrado duas vezes.

Como o Idempotency-Key corta a duplicidade na origem

A chave de idempotência é um identificador enviado junto com a requisição. O servidor guarda a chave e a resposta. Se a mesma chave chegar de novo, devolve a resposta original sem reprocessar.

Use um UUID gerado pelo cliente como Idempotency-Key em toda chamada que altera estado. O servidor precisa armazenar a chave por pelo menos 24 horas.

Fila morta: quando parar de tentar e investigar

Retry com backoff exponencial resolve picos passageiros. Mas tentar para sempre esconde um problema estrutural. A dead letter queue recebe as mensagens que falharam após N tentativas.

Investigar a fila morta deve ser rotina semanal. Cada mensagem ali é uma venda que não entrou no fluxo.

Quando o fornecedor não tem API: as saídas por ordem de risco

Nem todo sistema legado tem API. A ordem de risco importa mais que a velocidade de entrega.

1. RPA preenchendo tela de sistema legado: rápido, mas frágil a mudança de layout.
2. Arquivo em pasta monitorada: estável, mas lento e sem rastreio fino.
3. Acesso direto ao banco: poderoso, mas quebra a regra de encapsulamento e pode corromper dados.

RPA preenchendo tela de sistema legado

Um robô imita cliques e digitação. Funciona para tirar relatório ou cadastrar pedido em sistema sem API. O problema é que qualquer mudança de tela quebra o robô.

Arquivo em pasta monitorada e EDI com grandes varejistas

Exportar CSV para uma pasta e o outro sistema importar de tempos em tempos funciona, mas a latência é alta. EDI é o padrão formal para troca de documentos fiscais e pedidos com varejistas grandes.

Acesso direto ao banco e CDC: poder com responsabilidade

Ler tabela diretamente ou usar Change Data Capture permite reagir a mudanças em milissegundos. O risco é um update errado corromper o banco de produção e derrubar o sistema inteiro.

Se for o único caminho, isole o acesso em uma conta de leitura e monitore bloqueios de tabela.

Tempo real ou em lote: a conta que quase ninguém faz

Nem toda operação precisa de tempo real. Mas a falsa economia do lote pode custar caro em experiência e conciliação.

A latência que o negócio realmente precisa

Um relatório de fechamento pode rodar de madrugada. Um pedido pago precisa liberar o frete em segundos. Mapeie o tempo máximo aceitável por fluxo.

Por que a rotina noturna está perdendo espaço para eventos

Um lote noturno significa que o dado de ontem só aparece hoje. Quando o cliente pergunta pelo pedido, o atendente não tem resposta. Eventos entregam o dado no momento em que ele muda.

Quanto tempo e quanto custa integrar de verdade

O esforço não termina quando o fluxo sobe. A fase de observação é onde aparecem os casos de borda.

De duas a seis semanas de código — e até 60 dias de observação

Uma integração sob medida entre dois SaaS com API documentada leva de 2 a 6 semanas de desenvolvimento. Depois, 30 a 60 dias observando comportamento em produção, ajustando retry, mapeando erros 429 e validando idempotência.

Se alguém prometer integrar em um dia e sem observação, desconfie.

O custo que cresce depois do go-live

Integração nativa tem custo inicial baixo, mas cada mudança de regra vira ticket com o suporte. Desenvolvimento customizado tem custo inicial alto, mas você controla a evolução.

O custo real está na manutenção: monitorar, corrigir contrato quebrado e adaptar à LGPD.

O que mudou recentemente: IA, agentes e webhooks assinados

O cenário de integrações passou a incluir assistentes de IA como consumidores de conectores. Plataformas publicaram integrações nativas para assistentes de IA.

Agentes low-code executam integrações em linguagem natural, transformando prompts em fluxos. E webhooks assinados com HMAC viraram padrão mínimo de segurança.

A pressão da LGPD também empurrou para registro de consentimento e trilha de auditoria em toda sincronização de dado pessoal.

Integrações nativas para assistentes de IA

Uma integração nativa permite que um assistente leia dados do CRM e dispare ações, sem o usuário montar a chamada na mão. Isso muda o perfil de quem opera integrações.

Agentes que montam integrações em linguagem natural

Dentro de plataformas low-code, um agente pode receber um comando como quando um lead chegar no formulário, adiciona no CRM e manda mensagem no WhatsApp e traduzir para um fluxo executável.

O risco é a falta de validação de contrato nesses fluxos gerados. A curadoria humana continua essencial.

Checklist final: desenhe uma integração que não vira dívida técnica

Pouca gente enxerga a decisão como uma matriz de quatro eixos: volume diário, criticidade do dado, time técnico próprio e velocidade de mudança do negócio. Cruzar esses fatores aponta a rota com mais clareza do que comparar preço ou lista de recursos. O volume sozinho não decide; a criticidade do dado decide se você pode conviver com uma integração pronta ou precisa de desenvolvimento customizado.

Você não precisa saber programar para começar. Precisa saber responder qual dado não pode falhar e quanto atraso a operação tolera.

Pegue um fluxo pequeno e aplique o checklist: fonte da verdade, contrato documentado, autenticação com OAuth ou chave, retry com backoff e idempotência. Rode em sandbox, depois em produção com monitoramento.