O gestor precisa entender o problema para priorizar o investimento, o CTO precisa reconhecer os padrões para corrigi-los.
O cliente compra no marketplace, estoque não é baixado no ERP, o mesmo produto é vendido duas vezes.
Ou pedido aprovado na plataforma, nota fiscal não emitida porque a integração com o ERP falhou silenciosamente.
Ou preço atualizado no ERP, mas o marketplace ainda está vendendo pelo preço antigo três dias depois.
Esses não são cenários hipotéticos.
São os problemas mais relatados por operações de e-commerce de médio e grande porte no Brasil.
Integração entre sistemas é tratada como problema técnico, mas as consequências são de negócio — venda cancelada, cliente insatisfeito, multa de marketplace por inconsistência de dados, custo operacional de correção manual.
O triângulo problemático
ERP, plataforma de e-commerce e marketplaces foram construídos com lógicas completamente diferentes — e raramente pensando uns nos outros.
O ERP pensa em transações financeiras, notas fiscais, centros de custo. Seu modelo de dados é orientado a documentos fiscais e contabilidade.
A plataforma de e-commerce pensa em catálogo, vitrine, checkout e experiência do cliente. Seu modelo de dados é orientado a produtos, sessões e pedidos.
O marketplace pensa em volume, vendedores e comissão. Seu modelo de dados é orientado a listings, sellers e SLAs de entrega.
Três sistemas com modelos de dados distintos, ciclos de atualização diferentes, APIs com contratos próprios e — no caso dos marketplaces — regras que mudam sem aviso prévio.
A integração entre eles não é só conexão técnica. É tradução constante entre três línguas diferentes, em tempo real, com tolerância próxima de zero a erro — porque qualquer falha se manifesta como problema visível para o cliente ou para o marketplace.
Esse contexto explica por que integrações nesse triângulo falham com tanta frequência — e porque falhas que parecem simples de resolver na superfície têm raízes mais profundas na arquitetura.
Os erros mais comuns
Divergência de estoque entre canais
O erro mais frequente e o de maior impacto direto em vendas.
Um SKU tem 10 unidades em estoque. O produto está disponível no site da loja e em três marketplaces simultaneamente.
Chegam quatro pedidos quase ao mesmo tempo — dois no Mercado Livre, um no site, um na Amazon.
O estoque real é 10, mas cada canal está olhando para um número que não foi atualizado em tempo real. Resultado: overselling. Pedidos confirmados que não podem ser atendidos.
Sincronização em batch, não em tempo real. A integração roda de hora em hora, ou a cada 15 minutos.
No intervalo entre uma sincronização e outra, vendas acontecem em múltiplos canais sem que nenhum deles saiba.
Ausência de reserva de estoque no momento do checkout. O estoque só é baixado após confirmação de pagamento.
No intervalo entre o cliente iniciar o checkout e o pagamento ser confirmado — que pode ser minutos — o mesmo produto pode ser vendido em outro canal.
Estoque físico e estoque disponível tratados como o mesmo número. Produtos em separação, em trânsito entre CDs ou com avaria não deveriam estar disponíveis para venda, mas frequentemente estão porque a integração não distingue esses estados.
Reserva de estoque no momento do início do checkout, não da confirmação do pagamento. Sincronização por evento, não por polling, quando o estoque muda, todos os canais são notificados imediatamente.
Buffer de segurança configurável por SKU para absorver o lag de sistemas mais lentos.
Marketplaces penalizam vendedores com alta taxa de cancelamento por falta de estoque.
Dependendo do histórico, a penalidade pode ser redução de visibilidade dos anúncios ou suspensão temporária da conta, impacto que vai muito além do pedido cancelado.
Falha silenciosa na emissão de nota fiscal
Este é o erro que mais demora para ser descoberto — e o que gera mais custo de correção quando aparece.
Pedido é aprovado na plataforma de e-commerce. A integração com o ERP deveria disparar a emissão da nota fiscal automaticamente.
A integração falha — por timeout, por dado faltante no pedido, por mudança no schema da API do ERP que não foi refletida no integrador.
A nota não é emitida. O produto é separado e enviado sem nota.
Ou pior: a operação só descobre dias depois quando o cliente pergunta pelo DANFE.
Ausência de confirmação explícita de sucesso. A integração envia o pedido para o ERP e assume que funcionou.
Não verifica se a nota foi emitida, não tem mecanismo de retry em caso de falha, não alerta ninguém quando algo dá errado.
Tratamento de erro inexistente ou inadequado. Quando a chamada ao ERP retorna erro, a integração registra no log e segue em frente.
Ninguém lê o log. O pedido continua no fluxo como se estivesse normal.
Dependência de dados que nem sempre estão presentes. ERP exige CNPJ do cliente para pedido B2B, mas a plataforma não obriga o preenchimento.
A integração quebra em uma subcategoria específica de pedidos que só aparece em volume.
Confirmação explícita de cada etapa do fluxo, pedido recebido pelo ERP, nota emitida, chave da nota retornada.
Fila de reprocessamento automático para falhas transitórias.
Alerta operacional imediato quando uma nota não é emitida dentro do tempo esperado após aprovação do pedido.
Preço desatualizado em marketplace
Gestor atualiza o preço de um produto no ERP ou na plataforma de e-commerce. A atualização deveria se propagar para todos os marketplaces.
Não se propaga, ou se propaga para dois dos três, ou se propaga com atraso de horas. O marketplace continua vendendo pelo preço antigo.
Dois cenários ruins: o preço novo é maior (a loja perde margem em cada venda até a atualização chegar) ou o preço novo é menor (o marketplace continua vendendo mais caro, prejudicando a competitividade do anúncio).
APIs de marketplace com rate limit. Quando há muitas atualizações simultâneas, o marketplace limita o número de chamadas por minuto.
Atualizações de baixa prioridade ficam na fila e chegam horas depois.
Atualização em cascata sem priorização. Quando o gestor atualiza 500 produtos de uma vez, todos entram na fila com a mesma prioridade.
Um produto estratégico espera na fila atrás de 499 outros.
Falta de confirmação de recebimento.
A integração envia a atualização de preço mas não verifica se o marketplace confirmou e aplicou. Em caso de falha na recepção, a atualização simplesmente não acontece.
Fila de atualização com priorização por impacto financeiro. Confirmação de aplicação do novo preço com checagem posterior.
Alerta quando divergência de preço entre sistemas ultrapassa determinado threshold ou tempo.
Pedido duplicado ou pedido fantasma
O mesmo pedido aparece duas vezes no ERP. Ou aparece na plataforma de e-commerce mas nunca chega ao ERP.
O primeiro gera nota fiscal dupla e separação duplicada. O segundo gera pedido não processado que o cliente está esperando.
Retry sem idempotência. Quando uma integração falha ao enviar um pedido, ela tenta de novo — sem verificar se o primeiro envio chegou parcialmente.
O ERP recebe o pedido duas vezes e processa as duas.
Webhook recebido mais de uma vez. Marketplaces e gateways de pagamento podem disparar o mesmo evento webhook múltiplas vezes (em caso de timeout na confirmação de recebimento).
Se a integração não trata duplicatas, processa o pedido duas vezes.
Race condition no processamento. Dois processos tentam criar o mesmo pedido simultaneamente, cenário possível em integrações com múltiplos workers sem controle de concorrência.
Toda operação de criação de pedido precisa ser idempotente, receber o mesmo pedido duas vezes deve ter o mesmo efeito de receber uma vez.
Chave de idempotência explícita em todas as chamadas de integração. Deduplicação na camada de recebimento antes do processamento.
Atributos de produto incompatíveis entre sistemas
O ERP categoriza produtos por código NCM e unidade de medida fiscal. A plataforma de e-commerce categoriza por categoria de vitrine e atributos de filtragem.
O marketplace exige categoria específica da taxonomia dele, com atributos obrigatórios próprios que não existem nos outros sistemas.
Um produto que está perfeitamente cadastrado no ERP pode ser rejeitado pelo marketplace por falta de atributo obrigatório, cor, voltagem, garantia em meses, que simplesmente não existe no modelo de dados do ERP.
Integração construída mapeando apenas os campos que existem nos dois sistemas.
Os campos que existem num e não no outro são ignorados ou preenchidos com valor padrão.
O marketplace rejeita o produto silenciosamente ou publica com dados incompletos que prejudicam a conversão.
Camada de transformação explícita entre os modelos de dados dos sistemas — não mapeamento direto campo a campo.
Validação dos atributos obrigatórios por marketplace antes do envio, com alerta quando um produto não pode ser publicado por dado faltante.
Enriquecimento de dados na camada de integração para campos que podem ser derivados ou padronizados.
O padrão por trás de todos esses erros
Não são problemas de tecnologia, são problemas de arquitetura de integração. Especificamente, três características ausentes na maioria das integrações problemáticas:
- Ausência de confirmação explícita de cada etapa: Integração que envia e esquece é integração que falha silenciosamente. Cada operação crítica — baixa de estoque, emissão de nota, atualização de preço — precisa de confirmação de que chegou, foi processada e o resultado foi o esperado.
- Ausência de tratamento de erro com ação: Log de erro que ninguém lê é ruído. Erro precisa gerar ação: retry automático para falha transitória, alerta operacional para falha persistente, escalação para intervenção humana quando o retry esgota.
- Ausência de observabilidade do fluxo completo: Quando um pedido sai da plataforma de e-commerce e precisa passar pelo antifraude, pelo gateway, pelo ERP e pelo sistema de logística, cada etapa precisa ser rastreável. Sem visibilidade do fluxo completo, quando algo dá errado o diagnóstico é um trabalho de investigação que pode levar horas.
Integração robusta não é integração que nunca falha. É integração que falha de forma visível, controlada e recuperável.
Middleware vs. integração direta
Existem duas abordagens básicas para conectar ERP, plataforma e marketplaces: integração direta ponto a ponto, ou uma camada intermediária (middleware ou plataforma de integração).
Integração direta ponto a ponto
Cada sistema fala diretamente com cada outro. Mais simples de implementar inicialmente.
Vira um problema de manutenção quando o número de sistemas cresce, cada novo canal adicionado exige N novas integrações com cada sistema existente.
Funciona bem para: operações com poucos canais e baixo volume de SKUs e pedidos, onde a complexidade não justifica uma camada adicional.
Middleware ou plataforma de integração
Uma camada central que recebe dados de todos os sistemas, transforma e distribui.
Cada sistema só precisa se conectar ao middleware — não a todos os outros sistemas.
Funciona bem para: operações com múltiplos marketplaces, ERP complexo, alto volume de pedidos ou frequentes mudanças nos canais de venda.
A escolha não é técnica, é proporcional à complexidade da operação.
O erro é usar integração direta numa operação que já cresceu além do que ela suporta, por inércia ou por não querer investir na arquitetura certa.
Sinais de que a integração atual está no limite
Seção prática que ajuda o leitor a diagnosticar a própria situação, e que cria urgência sem ser alarmista.
Indicadores de que a arquitetura de integração atual vai travar o crescimento:
- Time operacional gasta mais de 2 horas por dia corrigindo divergências entre sistemas manualmente
- Qualquer novo marketplace adicionado exige semanas de desenvolvimento e testes
- Taxa de cancelamento por falta de estoque está acima de 1–2%
- Incidentes de nota fiscal não emitida acontecem com qualquer frequência que não seja zero
- O time técnico não consegue responder em menos de uma hora onde está um pedido específico no fluxo de integração
- Cada mudança em um sistema exige verificar o impacto em todos os outros manualmente
Se mais de dois desses pontos são reconhecíveis, a integração atual não é apenas ineficiente, está ativamente limitando o crescimento da operação.
Para fechar
Integração entre ERP, plataforma e marketplaces é uma das infraestruturas mais críticas de um e-commerce e uma das mais negligenciadas em termos de arquitetura.
Os erros não são raros, são o padrão em operações que cresceram rapidamente e não revisaram a arquitetura de integração no mesmo ritmo.
A boa notícia, todos eles têm solução conhecida. A má notícia, a solução exige investimento em arquitetura, não só em correções pontuais.
A Dupla projeta e implementa integrações entre ERP, plataformas de e-commerce e marketplaces com arquitetura pensada para escalar.
Se a sua operação está convivendo com algum dos problemas descritos aqui, fale com a gente.