Integrar a loja virtual com o ERP é definir, antes de qualquer código ou conector, qual sistema manda em cada dado, quando a informação passa de um para o outro e o que acontece quando a passagem falha. Sem essas três respostas, a integração até funciona no dia do teste, mas gera pedido duplicado, estoque negativo ou preço diferente no primeiro pico de vendas.
Este guia é para quem já usa um ERP, ou vai passar a usar, e precisa colocar a integração no escopo da criação da loja. Ele não indica conectores: a disponibilidade de cada um depende da plataforma, do plano e do fornecedor do ERP, e precisa ser conferida na documentação deles. Se você ainda está montando o documento de requisitos, a seção de sistemas do modelo de briefing da loja virtual é o ponto de partida; aqui o assunto é o detalhamento que o fornecedor da integração precisa para orçar.
Qual sistema é a origem oficial de cada dado?
Faça a pergunta dado por dado, e às vezes campo por campo. As respostas abaixo são as mais frequentes, mas não são regra.
Produto. O cadastro fiscal (código, nome fiscal, unidade, dados tributários) costuma nascer no ERP. O conteúdo de vitrine (descrição comercial, fotos, categoria da loja, texto de busca) costuma nascer na loja, porque o ERP não foi feito para isso. Dividir o produto em dois grupos de campos evita que uma sincronização apague a descrição escrita para o site.
Estoque. Se há loja física, depósito ou outro canal, a origem tende a ser o ERP, e a loja só lê o saldo disponível para venda online. Defina se existe estoque de segurança, que é uma quantidade que a loja não mostra para absorver a defasagem entre os sistemas.
Preço. Pode nascer em qualquer um dos dois, mas só em um. Promoções criadas no painel da loja precisam de regra própria: o ERP recebe o preço praticado no pedido, mesmo sem conhecer a promoção.
Cliente. No varejo, o cadastro costuma nascer no checkout da loja e seguir para o ERP com o primeiro pedido. No B2B, pode ser o inverso: o cliente é aprovado no ERP e só então ganha acesso à loja.
Pedido. Nasce na loja. O ERP passa a ser a origem do andamento: separação, faturamento, envio. A loja recebe esses status para mostrar ao cliente.
Nota fiscal. É emitida no ERP ou no emissor ligado a ele. A loja recebe número e chave de acesso, quando precisa exibi-los ao cliente ou repassá-los à transportadora.
Com que frequência os dados passam e o que fazer quando algo falha?
Há três formas de mover um dado: por evento, quando um sistema avisa o outro assim que algo acontece (webhook); por intervalo, quando um sistema consulta o outro de tempos em tempos; e por lote, quando a troca é manual ou agendada para um horário. Pedido pago e estoque costumam pedir evento ou intervalo curto. Cadastro de produto aceita intervalo maior.
A troca por evento parece instantânea, mas as plataformas documentam limites que o projeto precisa tratar. Na documentação da API da Nuvemshop, consultada em 20/10/2026, o webhook espera uma resposta de sucesso em até 3 segundos; sem resposta, a plataforma reenvia o aviso até 16 vezes ao longo de 48 horas. A mesma página avisa que os avisos podem chegar fora de ordem e repetidos, e que garantir a idempotência é responsabilidade de quem integra. A documentação de desenvolvedores da Shopify, consultada na mesma data, diz que a ordem dos webhooks não é garantida, que a entrega também não é, e recomenda rotinas de reconciliação que busquem periodicamente os dados na plataforma.
Na prática, isso vira quatro requisitos:
- Conflito. Quando os dois sistemas mudam o mesmo dado, vale a origem oficial, não o último a gravar.
- Duplicidade. O mesmo aviso processado duas vezes não cria dois pedidos nem baixa o estoque duas vezes.
- Registro. Cada troca grava data, hora, dado enviado, resposta e erro, num lugar que alguém da operação consegue consultar.
- Reconciliação. Uma rotina compara pedidos, estoques e preços entre os sistemas em horário definido e aponta ou corrige as diferenças.
Matriz de dados: origem, destino, regra e resposta a falha
A matriz abaixo foi preenchida com dados demonstrativos, para uma loja fictícia de varejo com loja física e ERP. Ela não descreve a integração de um cliente nem de um ERP específico. Copie a estrutura e troque cada linha pela realidade da sua operação.
| Dado / campo | Origem | Destino | Gatilho e frequência | Regra | Se falhar |
|---|---|---|---|---|---|
| SKU e código de barras | ERP | Loja | Ao cadastrar no ERP | Chave que liga os dois sistemas; nunca muda | Produto não é publicado; alerta para o cadastro |
| Nome fiscal, unidade, dados tributários | ERP | Loja (não exibidos) | Ao alterar no ERP | Loja não edita | Mantém o último valor; registra erro |
| Descrição, fotos, categoria da loja | Loja | Nenhum | Não sincroniza | ERP não sobrescreve | Não se aplica |
| Saldo disponível online | ERP | Loja | Por evento, com conferência a cada 15 minutos | Saldo do ERP menos estoque de segurança de 1 unidade | Produto fica indisponível até a próxima conferência |
| Preço de tabela | ERP | Loja | Ao alterar no ERP | Loja não edita o preço de tabela | Mantém preço anterior; alerta para o comercial |
| Preço promocional | Loja | ERP (no pedido) | Junto com o pedido | ERP registra o valor praticado | Pedido entra em fila de revisão |
| Cadastro do cliente | Loja | ERP | No primeiro pedido pago | CPF ou CNPJ identifica o cliente; não duplica | Pedido segue; cliente entra em fila de revisão |
| Pedido pago | Loja | ERP | Por evento, ao confirmar pagamento | Identificador do pedido impede duplicidade | Reenvio automático; depois de 1 hora, alerta |
| Pedido cancelado | Loja ou ERP | O outro | Por evento | Devolve o saldo ao estoque | Reconciliação diária identifica |
| Status de separação e envio | ERP | Loja | Por evento | Loja só exibe; não altera | Cliente vê último status; alerta se parado por 1 dia útil |
| Código de rastreio | ERP | Loja | Ao faturar | Enviado ao cliente pela loja | Atendimento envia manualmente |
| Número e chave da nota fiscal | ERP | Loja | Ao emitir | Exibidos no pedido do cliente | Fica disponível no ERP; atendimento envia |
Os intervalos de 15 minutos, 1 hora e 1 dia útil são valores de exemplo para mostrar onde a decisão entra. O certo para a sua loja depende do volume de pedidos, do giro do estoque e do que o conector ou a API permitem.
Conector, adaptação ou integração própria?
Com a matriz pronta, dá para comparar as três formas de entregar a integração pelo mesmo critério: quantas linhas cada uma cobre sem trabalho extra.
| Caminho | Quando cabe | O que conferir antes | Quem mantém |
|---|---|---|---|
| Conector disponível | Plataforma e ERP têm integração pronta e ela cobre as linhas da matriz | Documentação do conector, plano exigido nos dois lados, campos cobertos, frequência, mensalidade e canal de suporte | O fornecedor do conector |
| Conector com adaptação | O conector cobre a maior parte, mas falta um campo ou uma regra | Se o conector aceita configuração ou extensão, e quem responde pela parte adaptada | Fornecedor do conector e quem adaptou |
| Integração própria | Não há conector, ou as regras da matriz fogem do que ele faz | APIs dos dois sistemas, limites de uso, ambiente de teste, registro e reconciliação no escopo | Quem desenvolveu, por contrato de manutenção |
Um conector que não cobre a linha de pedido cancelado, por exemplo, deixa uma tarefa manual permanente para a equipe. Vale anotar essas lacunas na matriz antes de comparar preços. Quando nenhuma opção pronta cobre o que é indispensável, a decisão passa a ser entre simplificar a regra ou desenvolvê-la, como explica o guia sobre plataforma pronta ou sob medida. Para ver como essas escolhas se aplicam a uma plataforma específica, leia sobre a integração Tray e ERP.
Roteiro de teste de ponta a ponta
Faça os testes em ambiente de homologação, com o meio de pagamento em modo de teste e produtos de teste no ERP. Marque cada linha só quando o resultado aparecer nos dois sistemas.
- Cadastrar um produto com duas variações no ERP e conferir se ele aparece na loja com SKU, preço e saldo corretos.
- Escrever a descrição na loja, alterar o preço no ERP e conferir se a descrição continua intacta.
- Zerar o saldo no ERP e conferir se a variação fica indisponível na loja no prazo combinado.
- Fazer um pedido pago na loja e conferir se ele entra no ERP uma única vez, com cliente, itens, frete e desconto.
- Recusar um pagamento e conferir se nenhum pedido chega ao ERP como aprovado.
- Cancelar um pedido e conferir se o saldo volta nos dois sistemas.
- Faturar no ERP e conferir se status, rastreio e nota aparecem no pedido do cliente.
- Interromper a integração por alguns minutos, fazer um pedido e conferir se ele chega quando a conexão volta e se o registro mostra a falha.
- Reenviar o mesmo aviso de pedido pago e conferir se não surge pedido duplicado.
- Rodar a reconciliação com uma diferença proposital de estoque e conferir se ela é apontada ou corrigida.
Que condições afetam a integração?
- Plano e fornecedor. O mesmo conector pode exigir plano específico na plataforma, no ERP ou nos dois. Confirme na documentação de cada lado, com data da consulta.
- Responsabilidade. Escreva quem atende quando o pedido não chega: o fornecedor do ERP, o do conector ou quem fez a integração própria.
- Dados pessoais. Cadastro de cliente circula entre sistemas. Defina quem tem acesso aos registros de integração e por quanto tempo eles ficam guardados.
- Loja física. Se o estoque é compartilhado com o balcão, a defasagem entre venda física e online é o maior risco. O guia para levar a loja física para a internet trata dessa operação.
Próximo passo
Leve a matriz preenchida e o roteiro de teste para a conversa sobre a criação de loja virtual profissional: com eles, a integração entra no escopo com entregas que podem ser testadas. Se a matriz mostrou regras que nenhum conector cobre, a avaliação passa pelo desenvolvimento de e-commerce sob medida.
