Integração por canal
Integração da VTEX com o seu ERP
A VTEX é a plataforma de e-commerce mais usada por operações de médio e grande porte no Brasil, e é também a que mais exige clareza na divisão de responsabilidades: catálogo, preço e estoque não vivem no mesmo lugar. No modelo ERP-first, o seu sistema continua sendo a fonte da verdade — produtos, saldo, preços, pedidos e notas fiscais nascem e são controlados nele — e cada informação é publicada na API correta da VTEX. Abaixo estão os 9 ERPs com integração documentada.
Como funciona a integração ERP-first · Todos os ERPs integrados · Integração com a Tray · Integração com a Shopify
O que muda, na prática, ao integrar com a VTEX
- Catálogo, preço e estoque vivem em três APIs diferentes. É a característica que mais separa a VTEX das outras plataformas e a que mais muda o desenho do projeto. Produto e SKU nascem na Catalog API; o preço é responsabilidade da Pricing API; o estoque pertence à Logistics API. Tratar tudo como “atualizar o produto” não funciona aqui.
- Não existe saldo global: estoque é sempre por SKU e por armazém. A rota é
PUT /api/logistics/pvt/inventory/skus/{skuId}/warehouses/{warehouseId}. O mapa entre depósito ou filial do seu ERP e o warehouse da VTEX é parte do projeto, não detalhe de implantação — é ele que permite atender regiões diferentes com políticas de saldo diferentes sem duplicar catálogo. - O preço tem endpoint próprio, com preço base e tabelas. A Pricing API trata o preço fixo por SKU em
PUT /pricing/prices/{itemId}e também as tabelas de preço. Uma operação com mais de uma política comercial precisa decidir o que o ERP controla e o que fica na plataforma. - Os pedidos seguem o modelo OMS, com estados próprios. A Orders API não devolve apenas o pedido: ela reflete uma esteira com etapas. O documento fiscal precisa ser emitido no ERP e comunicado no estado certo, senão o pedido trava na esteira mesmo com a NF-e já autorizada.
- A autenticação é por chave e token de aplicação. Os cabeçalhos são
X-VTEX-API-AppKeyeX-VTEX-API-AppToken. Várias APIs também aceitam token de usuário, mas para integração servidor a servidor o par de aplicação é o caminho estável. - Os limites são documentados e diferentes por API. A Pricing API, por exemplo, publica teto de 2.000 requisições por minuto em POST e PUT, com créditos de burst e cabeçalhos
Ratelimit-*eRetry-After. Carga inicial e sincronização contínua precisam de estratégias distintas.
TOTVS WinThor + VTEX
Estoque por filial do WinThor mapeado nos warehouses da VTEX.
SAP Business One + VTEX
Cadeia de documentos preservada e NF-e emitida dentro do SAP B1.
TOTVS Protheus + VTEX
TES correta na entrada do pedido e faturamento no Protheus.
Linx Microvix + VTEX
Lojas físicas e e-commerce publicando o mesmo estoque.
Consinco + VTEX
Operação de supermercado com fiscal e estoque no Consinco.
Sankhya + VTEX
TOP correta, estoque por depósito e NF-e no Sankhya.
SAP S/4HANA + VTEX
Arquitetura, sincronização e governança no núcleo do S/4HANA.
E-Millennium + VTEX
Pedidos, estoque e logística conectados ao E-Millennium.
Hiper + VTEX
Catálogo, preço e estoque tratados nas APIs certas da VTEX.
Usa outro ERP e vende na VTEX?
A lista acima cobre os sistemas com integração já documentada, mas a arquitetura da Plugar.me é agnóstica de ERP: onde existe API, view ou base acessível, existe caminho. O ponto de partida em qualquer projeto VTEX é o mesmo — definir de qual depósito sai o saldo de cada warehouse, quem controla o preço e em que estado do OMS a nota fiscal é comunicada.