Quando o hub de integrações vira um ERP de e-commerce independente

O lojista que cresce no e-commerce brasileiro vive uma armadilha silenciosa. Cada novo canal, cada nova plataforma, cada novo marketplace, traz a sua própria forma de guardar produto, preço e estoque. O que começa como uma loja vira uma colcha de retalhos de sistemas que não se enxergam. A tese contraintuitiva é que a solução está em inverter a arquitetura, e não em integrar melhor essas peças: tirar o core operacional de dentro dos canais e colocá-lo em um núcleo único que os canais apenas consultam.

Esse núcleo único é o que diferencia um e-commerce que escala de um que trava. O mercado dá o sinal. As lojas nacionais respondem por 92% das vendas de e-commerce no Brasil (PCMI, 2024), o que significa que o problema de integração é doméstico, feito de múltiplos ERPs legados, gateways locais, Pix e marketplaces nacionais. E o e-commerce B2B cresce a 18,42% ao ano até 2031 (Mordor Intelligence, 2025), trazendo ainda mais sistemas para dentro do fluxo. Quanto mais peças, mais valor em ter um centro que as governe.

O que significa desacoplar o core operacional dos canais?

Resposta direta: significa que estoque, preço, cadastro fiscal e crédito deixam de morar dentro da loja ou do marketplace e passam a morar em um núcleo próprio. Os canais viram consumidores desse núcleo, não donos dele. Trocar de canal não toca mais no core, porque o core nunca esteve dentro do canal.

A imagem é de três camadas empilhadas. Em cima, a camada de canais: loja própria, app, marketplace, social commerce, PDV físico. Essa camada é volátil, muda com a moda e com a estratégia comercial. No meio, o hub de integrações, que orquestra os eventos entre tudo. Embaixo, o ERP de e-commerce, que guarda a verdade operacional. Quando essas camadas estão separadas, mudar a de cima não mexe na de baixo. É essa separação que sustenta o mantra da Onclick de que a loja não para, porque o que muda é a vitrine, não o núcleo.

O contraste com o ERP legado genérico é o ponto. Um ERP de prateleira foi pensado para a indústria ou para o varejo de loja física, e o e-commerce foi enfiado nele à força, como mais um módulo. O resultado é um sistema que não entende saldo por variação de grade, repasse de marketplace, split de pagamento ou feed por canal. O ERP de e-commerce independente nasce do problema certo. Ele assume desde o início que o pedido vem de muitos canais, que o dinheiro chega de muitas formas e que a vitrine vai mudar. Esqueça o ERP de sempre com um plugin de loja: aqui o núcleo já nasce desenhado para o comércio multicanal.

A folha de conexão com plataformas mostra a camada de cima, e a folha de hub de integrações pela ótica da operação mostra o meio. Aqui o foco é a camada de baixo virando independente.

A tendência de mercado confirma o desenho. Arquiteturas que separam vitrine de núcleo, o chamado modelo headless, deixaram de ser exóticas. Empresas adotam composição de serviços justamente para trocar a camada de experiência sem mexer no core. A lógica é a mesma do ERP de e-commerce independente: a vitrine é descartável, o núcleo é permanente. O que muda de nome de tempos em tempos, headless, composable, microsserviços, descreve sempre a mesma decisão de arquitetura: desacoplar o que muda do que não pode mudar.

Quando um hub de integrações deixa de ser só hub?

Resposta direta: quando ele passa a guardar a verdade operacional, não só a traduzir mensagens. Um hub que apenas conecta APIs é um tradutor. Um hub que reúne saldo único, regra de preço por canal e cadastro fiscal em um lugar acessível por todos os canais já se comporta como um ERP de e-commerce.

A fronteira é sutil mas decisiva. Um iPaaS genérico move dados de um lado para o outro e não opina sobre eles. O APIECOMM faz mais: ele se apoia no ERP Onclick e no KPL para que o pedido que entra de qualquer canal encontre um saldo único, uma política de preço e um motor fiscal já prontos. O Pix, que respondeu por 40% do volume de pagamentos do e-commerce em 2024 (PCMI, 2024), e o cartão de crédito, com 34% (PCMI, 2024), chegam por gateways diferentes e são reconciliados no mesmo lugar. Vai além de conexão: funciona como um núcleo operacional que os canais alimentam e consultam.

O domínio do problema é nacional, e isso muda o desenho. Como 92% das vendas de e-commerce no Brasil vêm de lojas nacionais (PCMI, 2024), o backend não precisa resolver o mundo, precisa resolver o Brasil bem. Pix, parcelamento sem juros, substituição tributária, nota fiscal eletrônica, repasse de marketplace nacional, transportadora brasileira. Um ERP de e-commerce independente que domina essas particularidades vale mais para o lojista daqui do que uma plataforma global que trata o Brasil como exceção. A independência não é só da vitrine, é a liberdade de ter um núcleo que fala a língua fiscal e financeira do país.

Por isso a expressão ERP de e-commerce independente faz sentido. Independente da plataforma de vitrine, independente do marketplace, independente do gateway. O núcleo permanece estável enquanto tudo ao redor muda. E como os marketplaces reconfiguram o próprio share a cada doze a dezoito meses, ter um core que não depende de qual canal está em alta é o que reduz o custo de mudança a quase zero.

Por que isso reduz o custo de trocar de canal?

Resposta direta: porque a troca de canal vira uma operação de conector, não de migração. Com o core fora dos canais, ligar um marketplace novo ou trocar de plataforma não exige recadastrar produto, reescrever regra fiscal ou reconfigurar estoque. Tudo isso já vive no núcleo, pronto para o próximo canal consumir.

A conta fica clara num exemplo. Um varejista de calçados quer entrar na Shopee depois de já vender no Mercado Livre e na loja VTEX. Com core acoplado aos canais, ele recadastra o catálogo inteiro na Shopee, recria as regras fiscais e arrisca dessincronizar o estoque. Com core independente, ele ativa o conector da Shopee no APIECOMM, e o catálogo, o preço e o saldo que já existem no núcleo fluem para o novo canal. Dias de trabalho viram horas. A folha de feeds e PIM detalha como o catálogo do núcleo se distribui assim.

O custo de mudança baixo muda o comportamento comercial. Quando entrar num canal novo é caro, o lojista hesita, e a hesitação custa venda. Quando é barato, ele testa. Abre na Shopee para a campanha de fim de ano, ativa um marketplace de nicho para uma coleção, experimenta o social commerce sem medo de quebrar a operação. A arquitetura independente transforma a estratégia de canal de uma aposta de alto risco em uma série de experimentos baratos. Os marketplaces reconfiguram o próprio share a cada doze a dezoito meses, e quem pode trocar de canal sem dor acompanha esse movimento, em vez de ficar preso ao canal que já foi bom.

Como saber se a sua operação precisa de um core independente?

Resposta direta: conte quantos cadastros do mesmo produto você mantém. Se o mesmo item existe cadastrado na loja, no marketplace e na planilha de estoque, com chance de divergir, você tem o core espalhado pelos canais. Um cadastro por produto, consultado por todos, é o sinal de um core independente saudável.

Aqui vai o quadro de decisão para levar embora. Faça três perguntas sobre cada dado crítico: estoque, preço e cadastro fiscal. Primeira, esse dado existe em quantos lugares hoje? Segunda, se ele divergir entre lugares, qual é a versão verdadeira? Terceira, trocar de canal me obriga a recriar esse dado? Se as respostas revelam dado duplicado, verdade ambígua e recriação a cada canal, a sua operação está pagando o imposto do core acoplado, mesmo que a fatura do software não mostre.

Esse imposto tem um nome operacional: tempo de gente sênior gasto reconciliando o que deveria ser único. É o analista que cruza a planilha de estoque com o painel do marketplace, o financeiro que confere se o preço do site bate com o do anúncio, o fiscal que corrige nota porque o CFOP saiu errado de um canal específico. Nenhum desses trabalhos aparece como custo de software, mas todos consomem as pessoas mais caras da operação. Um core independente devolve esse tempo, porque a reconciliação some quando não há duas versões para reconciliar. O retorno do desacoplamento não está na licença, está na folha de quem para de apagar incêndio.

• Um cadastro por produto, não um por canal.
• Um saldo único, consultado por todas as vitrines em tempo real.
• Uma regra fiscal central, distribuída para os canais, nunca duplicada.
• Um motor de crédito e conciliação que enxerga todos os canais ao mesmo tempo.

O próximo passo é desenhar a sua arquitetura em três camadas e marcar onde cada dado mora hoje. Se estoque, preço e fiscal estão na camada de canais, eles estão no andar errado. Movê-los para um ERP de e-commerce independente, ligado aos canais por um hub, é a obra que transforma crescimento em operação sustentável. Para ver como esse núcleo fala com agentes de IA que leem o backend, siga para a folha sobre backend legível por agentes.