Catálogo e carrinho pela mesma API da Uappi. O mK Fashion+ tem módulo dedicado que lê o payload de compra já pronto para cada tamanho e adiciona por chamada direta, sem depender do botão da página, e reavalia o botão quando a variante muda sem a página recarregar.
No <head> do tema da loja, em todas as páginas.
<script src="https://unpkg.com/mk-sdk-git@1/dist/mk-sdk.js"
data-mk-project="SEU_PROJECT_ID"
data-mk-product="mk-fashion"
async></script>Troque SEU_PROJECT_ID pelo identificador do seu projeto. O atributo async garante que a tag não bloqueia o carregamento da página, e @1 fixa a major da versão: você recebe correção sem risco de um release novo mudar a loja sem aviso.
A metaKosmos cria o projeto e envia o identificador. Ele é o único valor que muda na tag, e não é segredo: vai no HTML público da loja.
Com as credenciais da API v2 da Uappi, o catálogo é importado com produtos, variações, preços e imagens. O acesso é renovado automaticamente, então a sincronização não para sozinha.
A tag precisa valer em todas as páginas, não só na de produto: é assim que o funil inteiro, da visita à compra, é medido. Se a sua operação usa gerenciador de tags, configure o disparo para todas as páginas.
É o teste que importa nesta plataforma. Abra um produto com mais de uma cor, troque entre elas sem recarregar e confirme que o botão acompanha: aparece nas cores que têm provador e some nas que não têm.
A importação usa a API v2 da Uappi e renova o acesso sozinha, porque o token da plataforma tem vida curta. A sincronização não para no meio por expiração de credencial.
A adição não depende de clicar o botão da página. O provador lê da própria API o payload de compra já pronto para o tamanho escolhido e o envia, então a peça entra no carrinho sem passar pelo comportamento do tema.
Nesta plataforma o botão nativo é ambíguo: um deles tem erro de digitação no rótulo e o outro é compra rápida, que leva o cliente embora da página. Acionar botão aqui seria frágil ou tiraria a pessoa do provador, e por isso a adição é por chamada direta.
O storefront da Uappi muda a variante sem recarregar a página, e um provador ingênuo continuaria mostrando a avaliação feita na abertura. O SDK observa essa troca e reavalia a disponibilidade na hora.
O botão de provar é injetado em Shadow DOM fechado, ancorado ao lado do comprar, com aparência controlada pelo painel. O CSS da loja e o nosso ficam isolados.
Visita, produto, carrinho e compra são detectados por sinais que a loja já emite. Nenhum evento manual, nenhuma mudança no checkout.
A resposta da adição já traz o carrinho atualizado, com subtotal e quantidade de itens. O valor chega ao painel sem uma segunda consulta, que é onde outras integrações perdem o dado.
Como a adição parte do endereço do produto e não do estado da página, o provador consegue adicionar uma peça de outro produto sem levar o cliente até a página dela. É o que permite comparar modelos lado a lado e comprar do próprio provador.
Na Uappi as duas metades da integração conversam com a mesma interface de programação da plataforma, o que é incomum e simplifica tudo.
O catálogo é servidor com servidor: a metaKosmos lê a API da Uappi, renova o acesso sozinha, porque o token tem vida curta, e importa produtos, variações, preços e imagens, re-sincronizando em horário configurado.
A loja é a tag no tema. Ela identifica a página de produto, injeta o botão e adiciona ao carrinho chamando a mesma API, do navegador do cliente, com o identificador de aplicação que a plataforma exige em toda requisição.
Na maioria das plataformas, a forma mais segura de adicionar é acionar o botão de compra do próprio tema, porque aí quem trabalha é a loja. Aqui é o contrário, e por um motivo concreto.
O botão nativo desta plataforma é ambíguo: um deles tem erro de digitação no rótulo, o que torna qualquer correspondência por texto frágil, e o outro é compra rápida, que redireciona o cliente e o tira do provador no meio da avaliação.
Então a adição é por chamada direta. O detalhe que torna isso confiável é que a própria resposta de detalhe do produto já traz, para cada tamanho, o payload de compra pronto: não é preciso montar nada nem adivinhar identificador. O provador escolhe o tamanho, pega o payload daquele tamanho e envia.
Vale entender a modelagem, porque ela muda o que o provador precisa resolver. Na Uappi, cada cor é um produto com endereço próprio. Os tamanhos são as variantes daquele endereço.
Isso simplifica metade do problema: a página já é a cor selecionada, então o provador nunca precisa descobrir de que cor é a peça. O que ele resolve é o tamanho, e a escolha segue uma ordem clara: o tamanho pedido no provador, senão o selecionado na página, senão o primeiro com estoque.
A outra metade é a troca de variante sem recarregar, comportamento do storefront da plataforma. O SDK observa essa troca e reavalia a disponibilidade, em vez de manter a avaliação feita na abertura da página.
O caminho completo é validado em loja Uappi em produção: adição com resposta de sucesso da API e leitura do subtotal do carrinho na mesma chamada.
Para conferir na sua loja antes de qualquer alteração, existe uma extensão de navegador que injeta o SDK em qualquer site e mostra a detecção de plataforma, a variante resolvida e o fluxo de carrinho. Dá para validar a integração inteira sem tocar no tema.
Sim, com módulo dedicado. Catálogo e carrinho usam a mesma API da plataforma, e a adição é por chamada direta, com o payload de compra que a própria loja entrega pronto para cada tamanho.
Porque nesta plataforma o botão é ambíguo: um tem erro de digitação no rótulo e o outro é compra rápida, que redireciona e tira o cliente do provador. A chamada direta é mais confiável e não interrompe a avaliação.
Sim. O storefront da Uappi troca a variante sem recarregar a página, e o SDK observa essa troca para reavaliar a disponibilidade em vez de manter a avaliação da abertura.
Não. O token da Uappi tem vida curta e a renovação é automática, então a importação não para no meio.
Não. É uma linha no <head> do tema, válida para todas as páginas. O botão de provar é injetado automaticamente na página de produto.
Não. A medição do funil usa sinais que a loja já emite, como URL, dados estruturados e cliques. Nenhum evento manual é necessário e o checkout não é alterado.