Virtual try-on API for online stores (and when embed is enough)

Teams searching for a virtual try-on API usually want one of three things: a product-page widget, a batch pipeline for catalog shots, or an agent/tool hook (MCP). You do not always need the API — sometimes a publishable key and a script tag are enough.

Decision tree

1. Single storefront, one product image URL → start with the embed snippet. Checkout stays yours.
2. Custom UI, mobile app, or server-side jobs → use the HTTP API with credit-based billing (/developers).
3. Agent / IDE workflows → MCP tools on the same credit ledger.

If you are still exploring the shopper journey, try the consumer studio first so you know what “good enough” looks like on real photos.

What the API is for

• Passing a person image + garment image (or garment URL your CDN already serves).
• Returning a result you store under your own product UX.
• Metering with credits instead of a surprise per-seat SaaS invoice.

It is not a size recommender. Tell shoppers the same thing we tell them on the marketing site: try-on is a visual check beside your size guide. Failure modes (lighting, sheer fabric, extreme pose) belong in your UI copy — borrow tone from where try-on struggles rather than inventing accuracy percentages.

Embed vs API (honest tradeoffs)

| | Embed | API / MCP | | -------------------- | ------------------------- | ------------------------ | | Time to first try-on | Minutes | Hours to a sprint | | UI control | Ours inside the widget | Yours | | Domain allowlist | Yes (pk_…) | Key + your backend rules | | Best fit | Indie / DTC product pages | Custom apps, automation |

Cross-store shoppers who never hit your domain may still use an any-store / extension path; that is a different distribution channel than your first-party API.

Implementation checklist

1. Create keys in settings; never ship secret keys to the browser.
2. Allowlist production domains for publishable keys.
3. Point garment input at the same image the PDP shows — mismatched crops confuse people more than the model.
4. Show remaining credits and a clear upgrade path when a job returns 402.
5. Log failures without dumping customer photos into public tickets.

Pricing stance

We bill in credits (see /pricing). Upstream model cost and our markup live in the product docs — this post will not invent benchmark tables we did not run. If you need an enterprise contract, contact us from the site; do not assume unlimited free API traffic.

Next step for builders: /developers. Next step for merchandisers who only need a widget: embed walkthrough.