Conversational Virtual Try-On: Previewing a Lipstick Inside the WhatsApp Thread

In Brazil, the shade question rarely starts on a website. It starts in a chat: the shopper sends a photo of the label, asks whether the lipstick "works on her", asks for help choosing between two foundation shades. A conversational virtual try-on answers exactly that moment — instead of replying with text and a link, the brand sends back the shopper's own image with the product applied. The decision happens inside the thread, with no channel switch.

This article is about designing that flow: what the API can render, how to organise human and automated service, and which limits need to be clear before go-live.

Why WhatsApp is a natural channel for virtual try-on

Three characteristics of the channel work in favour of virtual try-on.

The photo is already circulating. Sending a selfie on WhatsApp is a trivial gesture for the shopper — she doesn't have to learn a new interface, grant camera permission in a browser or install anything. The raw material for the try-on arrives on its own.

The conversation carries context. Before the photo, she has already said what she is looking for: a lipstick for work, a foundation for oily skin, a gift. That context narrows down the shade range worth showing.

The service channel already exists. Beauty brands, resellers and physical stores already run sales on WhatsApp. Try-on doesn't create a channel: it adds a visual answer to a channel that already converts.

How a conversational virtual try-on works in practice

MaIA Try-On comes in two delivery formats, and only one of them fits WhatsApp.

The photo-based API is the right piece

On WhatsApp, the flow is photo-based. The shopper sends the image, your backend receives the file through the messaging API webhook, forwards it to the MaIA Try-On API along with the product identifier, and receives the rendered image back. That image is returned as media in the conversation. The API renders lipstick and foundation, with palettes calibrated to the brand's real products inside a project — meaning the shade that shows up in the photo corresponds to the SKU in the catalog, not to a generic colour.

The browser SDK is a different thing: it covers thirteen products plus the Full Look, with a live camera mode rendered locally, and it is self-hosted by the brand on a web page. It does not run inside WhatsApp. If your script needs eyeshadow, mascara or a complete look, the path is to take the shopper to a page with the SDK — and there the link becomes the next step in the conversation, not the immediate answer. The difference between the two formats is detailed in the article on photo-based try-on and AR try-on.

The minimum conversation script

A lean flow usually has five steps:

1. Intent — the shopper asks about a product or a category.
2. Photo request — with a short instruction: face forward, natural light, no filter.
3. Shade selection — two or three shades, not the whole range. More than three images in a row become noise in the thread.
4. Sending the previews — each image accompanied by the SKU name and the product link.
5. Closing — a cart link, or a handover to a human agent.

Where the beauty profile fits

The preview shows how it looks. It does not decide which shades to show. That choice can come from the conversation, from a direct question, or from the beauty profile generated by MaIA Scan, which describes visible attributes of the photo — skin tone and undertone, apparent type and condition, hair attributes, with a confidence per field. It is a description of visible characteristics in an image, not a medical assessment, and it does not replace a professional.

With the profile in hand, the same photo serves two purposes: defining the shade selection and feeding the render. And if the brand wants the entire conversation to be led by an AI layer connected to the catalog, that is the scope of MaIA Beauty Advisor, delivered as a project with the B4A team.

Decisions that need to be made before go-live

Automated, human or hybrid

Human service with try-on works well at lower volumes and higher tickets: the agent triggers the render and comments on the result. Pure automation scales better in launch campaigns. The hybrid model — a bot collects the photo and generates previews, a human takes over when there is doubt — tends to be the most realistic design for teams that already sell in the channel.

What happens to the photo

In the API flow the photo leaves the shopper's device: it reaches WhatsApp, your backend and the render API. Decide in advance how long the image is stored on each side, who on the team can view it, and write that in plain language in the first message of the flow. Clear consent in a chat channel matters as much as render quality.

Quality of the photo you receive

WhatsApp photos arrive compressed, sometimes shot from far away, sometimes under yellow light. It pays to instruct the capture in one sentence and to have a standard reply for an unsuitable image — asking for another photo is better than returning a poor render, because the wrong preview destroys trust in the shade.

Catalog and naming

Every rendered shade needs a stable identifier linking the preview to a sellable SKU. Without it, the shopper likes the image and nobody knows which product to put in the cart.

What to measure

Track conversations with a photo sent, previews generated per conversation, clicks on the product link after the preview, and the close rate compared with conversations without try-on. Third-party numbers on the impact of virtual try-on exist, but results vary with each brand's catalog, traffic and channel — measure your own.

Want to test the flow? Create your account, buy credits and generate your key in the API documentation, or talk to the B4A team to design the conversation around your catalog.