API de try-on virtual ou SDK no navegador: qual se encaixa no seu stack

A maioria das equipes que avalia prova de maquiagem começa pela mesma pergunta, formulada de jeitos diferentes: chamamos um serviço a partir do nosso backend ou rodamos algo no navegador da cliente? Essa é a decisão entre API de try-on virtual e SDK no navegador, e ela tem menos a ver com qual é melhor e mais com onde está o seu tráfego, quem mantém o front-end e o que você precisa mostrar.

O MaIA Try-On existe nas duas formas. Não são duas versões da mesma coisa — elas renderizam catálogos diferentes de produtos, em lugares diferentes, com trabalho de integração diferente. Escolher a forma errada costuma aparecer tarde, quando a equipe descobre que prometeu um recurso que a forma escolhida não entrega.

O que cada forma faz de fato

A API: entra uma foto, sai uma imagem renderizada

Com a API do MaIA Try-On, o seu sistema envia uma foto e a referência de um produto. O produto — batom ou base — é renderizado no rosto daquela foto, e a imagem volta para você. Esse é o contrato inteiro. Os tons disponíveis são os calibrados para os seus produtos reais dentro do seu projeto, então o que a cliente vê corresponde a um SKU que ela pode de fato adicionar ao carrinho.

Como é uma chamada servidor a servidor, a API não se importa com o que é o front-end. Uma página de produto, um fluxo de WhatsApp, uma landing page de e-mail, uma tela de quiosque, um microsite de campanha — todos podem produzir uma imagem renderizada, desde que algo no meio consiga enviar uma foto e exibir o resultado.

O SDK no navegador: modo câmera ao vivo ou modo foto, renderizado localmente

O SDK do MaIA Try-On para navegador está em acesso antecipado desde setembro de 2026, liberado por conta. Ele cobre treze produtos — batom, base, blush, pó facial, corretivo para olheiras, sombra, máscara de cílios, maquiagem de sobrancelha, delineador, bronzer, contorno, iluminador e lápis de boca — mais um Full Look combinado. Roda em modo câmera ao vivo, em que a imagem da câmera da cliente é renderizada localmente no navegador e nada é enviado, ou em modo foto, sobre uma imagem que a cliente escolhe. Qualquer cor em #RRGGBB pode ser aplicada, e a marca hospeda o SDK na própria infraestrutura.

O limite importante: os onze produtos além de batom e base, e o Full Look, são prévias locais exclusivas do SDK. A API não os renderiza. Se o seu briefing diz "as clientes experimentam um look completo com sombra e blush", isso é um projeto de SDK, não de API.

API de try-on virtual ou SDK no navegador: como escolher

Escolha a API quando o render precisa viajar

Se a imagem renderizada precisa existir fora da sessão do navegador, a API é a resposta certa. Uma conversa no WhatsApp que devolve uma prévia, um e-mail de CRM com uma imagem personalizada, um marketplace que gera prévias para muitas paletas de marca, uma vendedora mostrando o resultado em um tablet — em todos esses casos, algo precisa de um arquivo de imagem, não de um canvas em uma página. A API também serve equipes cujo front-end é fechado, baseado em templates ou pertence a outro squad: a integração mora no seu backend e a superfície de contato na página é pequena.

Escolha o SDK quando a experiência precisa parecer imediata

Se o valor está em a cliente mexer a cabeça, trocar de tom e comparar looks em tempo real, isso é modo câmera ao vivo, e isso é o SDK. Também é a resposta quando o catálogo de efeitos importa: ninguém vai experimentar máscara de cílios ou delineador uma foto de cada vez. Hospedar o SDK na própria infraestrutura significa que a marca controla a distribuição e o front-end, o que equipes de engenharia com loja própria costumam preferir — e significa que alguém responsável pelo front-end precisa fazer parte do projeto desde o primeiro dia.

Uma nota de vocabulário, porque ela muda as expectativas em uma reunião de roadmap: nenhuma das duas formas é AR. Vale ler a comparação entre prévias por foto e experiências de AR antes de escrever o briefing — tratamos disso em try-on virtual vs try-on com AR.

O trabalho que é igual nos dois casos

Mapeamento de paleta e catálogo

As duas formas só são tão críveis quanto as cores por trás delas. Na API, os tons são calibrados para os seus produtos reais no seu projeto. No SDK, você passa os valores hexadecimais, o que significa que alguém do seu lado é dono do mapeamento entre um SKU e a cor com que ele é renderizado. Esse mapeamento é a entrega que ninguém orça e todo mundo precisa: uma planilha de produtos, nomes de tons, valores hex e os IDs de variante que o seu carrinho entende.

Decidir o que a cliente experimenta primeiro

Uma prova com quarenta tons e nenhum ponto de partida é um problema de navegação, não uma ferramenta de decisão. É aqui que uma análise de pele e cabelo ajuda: a API de análise de pele por selfie devolve tom e subtom de pele com uma confiança por campo, e você pode usar isso para pré-selecionar dois ou três tons antes de a prova abrir. A cliente ajusta a partir de um começo sensato em vez de rolar a lista.

Dá para rodar os dois?

Sim, e muitas equipes acabam aí. Uma divisão comum: a API alimenta os canais conversacionais e de campanha, onde uma imagem precisa ser enviada para algum lugar, enquanto o SDK alimenta a página de produto e a experiência de look completo no site da própria marca. O mapeamento de catálogo é compartilhado, assim como a camada de análise, se você usar uma.

Se ainda não tem certeza, comece pela API. Ela é self-service — crie uma conta, compre créditos, gere uma chave —, então você consegue ter uma prévia de batom ou base funcionando com os seus próprios tons em dias e aprender o que as clientes de fato fazem com ela. O acesso antecipado ao SDK é liberado por conta, então a conversa sobre o catálogo completo pode correr em paralelo.

Pronto para testar? Crie sua conta e sua chave de API na documentação da API do MaIA, ou fale com a nossa equipe sobre o acesso antecipado ao SDK e o mapeamento da sua paleta.