Beauty API Proof of Concept: A Two-Week Plan From Key to Demo

Most beauty API decisions stall in the same place: a long internal debate about a technology nobody on the team has actually called yet. A beauty API proof of concept fixes that. Instead of another vendor deck, you get a working endpoint, your own photos, your own catalog, and a demo your commercial team can click through. Two weeks of focused work is usually enough to know whether skin and hair analysis or makeup try-on deserves a slot in the roadmap.

This is a plan you can run with one developer and one person from e-commerce or CRM.

What to decide before you write the first line of code

The failure mode of a proof of concept is scope. Teams try to validate shade matching, skincare recommendations, a WhatsApp flow and a loyalty use case at once, then spend the whole period arguing about which one to show.

Pick one journey

Choose a single journey with a visible commercial outcome. Good candidates: a foundation finder on the product page, a skincare quiz that replaces self-declared questions with analysis of a selfie, a lipstick preview in a campaign landing page, or a profile capture that feeds CRM segments. Write it in one sentence: "A customer uploads a selfie on the foundation page and sees three shades ranked for her."

Define the output you need

List the fields your journey actually consumes. For a foundation finder that is skin tone and undertone. For a skincare quiz it is skin type and condition. For haircare it is hair attributes. Everything else in the response is context, not a requirement. MaIA Scan returns the beauty profile as JSON with a confidence value per field, so decide early what your interface does when confidence is low — ask for a second photo, or fall back to a question.

Agree on what a pass looks like

Define the acceptance criteria before you see any result, otherwise the review becomes a debate about taste. Reasonable criteria: the analysis runs end to end on real customer photos; the mapping from profile to SKU produces a shortlist a trained consultant would accept; the team can explain the recommendation to a customer in one sentence.

How to run a beauty API proof of concept in two weeks

Days 1 to 3: key, first call, sample set

Create the account, buy credits and generate an API key from the API documentation. The first call should be a single selfie and a printed JSON response — nothing else. In parallel, assemble a sample set of thirty to sixty real photos: different skin tones, different lighting, front camera and rear camera, some deliberately bad ones. Photos from your own customer base or your own team beat stock images, because they look like what your page will actually receive.

If your audience is Brazilian, note that MaIA Scan was trained on Brazilian skin. That matters most in the middle and deeper parts of the tone range, where generic models tend to collapse distinct shades into one bucket.

Days 4 to 7: connect the profile to your catalog

This is where the real work is, and it is not the API. Export the SKUs relevant to your journey and add the attributes the mapping needs: shade tone and undertone for foundation, finish and family for lipstick, hair type for haircare, skin concern tags for skincare. Then write the rules that turn a profile into a ranked shortlist. Keep it simple and readable — a scoring function you can print on one page is easier to defend in a review than a model nobody can inspect.

If the journey involves makeup preview, calibrate the palette to your real products rather than approximate hex codes. MaIA Try-On works photo-based through the API for lipstick and foundation, with palettes set per brand project; the browser SDK, in early access since September 2026, covers thirteen products plus a combined Full Look in live camera mode or photo mode, self-hosted by the brand. Pick the form that matches the surface you are testing.

Days 8 to 10: build one real surface

No slides. Build the actual page, modal or chat step your customer would use, even if it is unstyled. Include the states that matter: upload, processing, result, low confidence, retry, and the path to add to cart. A proof of concept that skips the error states will mislead everyone in the review.

Days 11 to 14: test with humans and review

Put the surface in front of ten to fifteen people who were not involved in building it — store consultants, customer service, colleagues who buy makeup. Watch where they hesitate. Then run the review with the acceptance criteria you wrote in week one, and record the open questions rather than hiding them.

What to judge, and what not to judge

Judge the end-to-end experience: does the profile plus your catalog produce a recommendation a human would make? Judge the integration effort: how many hours did it take, and what broke. Judge the fallback: what happens when the photo is dark, the face is partially covered or the customer refuses the camera.

Do not judge single-image edge cases as if they were benchmarks. One photo where the undertone looks arguable says less than thirty photos where the shortlist consistently makes sense. And remember what the output is: a description of visible attributes in a photo, useful for shade and product matching. It is not a diagnosis and it does not replace a professional.

From proof of concept to production

When the result is positive, the next decisions are operational: where the profile is stored, how often it is refreshed, who owns the catalog attributes, and which teams consume the segments. If the journey is conversational — WhatsApp, chat, a guided advisor on the product page — that is a project with the B4A team rather than a self-serve endpoint, because it depends on your catalog and your tone of voice.

If the result is negative, you still win: you spent two weeks instead of a quarter, and you know exactly which part failed.

Ready to start? Create your account, buy credits and generate an API key to run your first call today — or talk to our team if your proof of concept involves a catalog-integrated advisor.