Virtual Try-On API vs Browser SDK: Which One Fits Your Stack

Most teams evaluating makeup try-on start with the same question, phrased in different ways: do we call a service from our backend, or do we run something in the shopper's browser? That is the virtual try-on API vs browser SDK decision, and it is less about which one is better and more about where your traffic is, who maintains the front end, and what you need to show.

MaIA Try-On exists in both forms. They are not two versions of the same thing — they render different catalogs of products, in different places, with different integration work. Picking the wrong one usually shows up late, when a team discovers it promised a feature the chosen form does not deliver.

What each form actually does

The API: a photo in, a rendered image out

With the MaIA Try-On API, your system sends a photo and a product reference. The product — lipstick or foundation — is rendered on the face in that photo, and the image comes back to you. That is the whole contract. The shades available are the ones calibrated to your real products inside your project, so what the shopper sees corresponds to a SKU you can actually add to a cart.

Because it is a server-to-server call, the API does not care what the front end is. A product page, a WhatsApp flow, an email landing page, a kiosk screen, a campaign microsite — all of them can produce a rendered image as long as something in the middle can send a photo and display the result.

The browser SDK: live camera mode or photo mode, rendered locally

The MaIA Try-On browser SDK has been in early access since September 2026, granted per account. It covers thirteen products — lipstick, foundation, blush, face powder, under-eye concealer, eyeshadow, mascara, eyebrow makeup, eyeliner, bronzer, contour, highlighter and lip liner — plus a combined Full Look. It runs in live camera mode, where the shopper's camera feed is rendered locally in the browser and nothing is uploaded, or in photo mode on an image the shopper chooses. Any colour in #RRGGBB can be applied, and the brand self-hosts the SDK.

The important boundary: the eleven products beyond lipstick and foundation, and the Full Look, are SDK-only, local previews. The API does not render them. If your brief says "shoppers try a full look with eyeshadow and blush," that is an SDK project, not an API project.

Virtual try-on API vs browser SDK: how to choose

Choose the API when the render has to travel

If the rendered image needs to exist outside the browser session, the API is the right answer. A WhatsApp conversation that sends back a preview, a CRM email with a personalised image, a marketplace that generates previews for many brand palettes, a sales assistant showing a result on a tablet — in all of those, something needs an image file, not a canvas on a page. The API also fits teams whose front end is locked down, templated or owned by another squad: the integration lives in your backend and the surface area on the page is small.

Choose the SDK when the experience has to feel immediate

If the value is in the shopper moving their head, changing shades and comparing looks in real time, that is live camera mode, and it is the SDK. It is also the answer when the catalog of effects matters: nobody is going to try mascara or eyeliner one photo at a time. Self-hosting means the brand controls distribution and the front end, which engineering teams with their own storefront usually prefer — and which means a front-end owner has to be part of the project from day one.

A note on vocabulary, because it changes expectations in a roadmap meeting: neither form is AR. The comparison between photo-based previews and AR experiences is worth reading before you write the brief — we covered it in virtual try-on vs AR try-on.

The work that is the same either way

Palette and catalog mapping

Both forms are only as credible as the colours behind them. For the API, shades are calibrated to your real products in your project. For the SDK, you pass the hex values, which means someone on your side owns the mapping between a SKU and the colour it renders as. That mapping is the deliverable nobody budgets for and everybody needs: a spreadsheet of products, shade names, hex values and the variant IDs your cart understands.

Deciding what the shopper tries first

A try-on with forty shades and no starting point is a browsing problem, not a decision tool. This is where a skin and hair analysis helps: the beauty scan API returns skin tone and undertone with a confidence per field, and you can use that to pre-select two or three shades before the try-on opens. The shopper adjusts from a sensible start instead of scrolling.

Can you run both?

Yes, and many teams end up there. A common split: the API powers conversational and campaign channels, where an image has to be sent somewhere, while the SDK powers the product page and the full-look experience on the brand's own site. The catalog mapping is shared, and so is the analysis layer if you use one.

If you are not sure yet, start with the API. It is self-serve — create an account, buy credits, get a key — so you can have a lipstick or foundation preview working against your own shades in days and learn what shoppers actually do with it. Early access to the SDK is granted per account, so the conversation about the full catalog can run in parallel.

Ready to test it? Create your account and API key in the MaIA API documentation, or talk to our team about SDK early access and your palette mapping.