Storefront integration

Everything in the API up to this point — creating a product, adding images, enabling try-on — exists to make one moment possible: a customer on your storefront clicks a button and sees themselves (or their product) in try-on. This page covers that last step, independent of which platform your storefront runs on.

The two snippets

Each product page that should offer try-on needs two things: a button your customer clicks, and a script that knows how to open the try-on experience for that specific product.

Your product page

<!-- 1. The button your customer clicks (style it however you like) -->
<button type="button" data-tryon-product-id="PRODUCT_ID">Try On</button>

<!-- 2. The bootstrap script for THIS product -->
<script async
  src="https://api.integration.tryonvirtual.com/api/v1/tryon/scripts/embed/bootstrap.js?shop_slug=YOUR_SHOP_SLUG&productId=PRODUCT_ID">
</script>

PRODUCT_ID is either the id this API returns for the product, or your own external_id if you set one — the two are interchangeable here in the storefront snippet. (REST endpoint paths like /v1/products/{id} always take the TryOn id — see Using your own IDs for the full scoping and a lookup-then-act pattern for when you only have the external_id.) See that same page if you’d rather your templates never store our ids at all.

Find YOUR_SHOP_SLUG in the panel under Settings → Shop.

The script is scoped to one product per page — it ships with that product’s try-on manifest already inlined, so there’s no extra network round-trip when the customer clicks the button. This is a hard limit, not just a convention: every bootstrap script defines the same window.openTryOn global, so loading a second one on the same page overwrites the first rather than adding a second product. For a page that lists or bundles multiple products (a grid, a quick-view card, a bundle page), link each product to its own product page rather than trying to offer try-on for more than one product inline.

How the button binds

Any element on the page carrying data-tryon-product-id is bound automatically once the DOM has finished loading — no extra JavaScript required on your end. If you want to trigger try-on from your own UI instead (a custom “Try it on” link, an image overlay, a menu item), call the bootstrap script’s global function directly:

Trigger it yourself

<a href="#" onclick="window.openTryOn(); return false;">See it on you</a>

window.openTryOn() opens the same experience the bound button would, using the productId the script tag was loaded with.

Only render for ready products

Not every product is ready to show a working try-on experience. Before you render either snippet on a page, check the product’s current state:

Request

curl https://api.integration.tryonvirtual.com/v1/products/TRYON_PRODUCT_UUID \
  -H "Authorization: Bearer tryon_sk_your_key"

TRYON_PRODUCT_UUID here is the TryOn id (a UUID) — REST paths don’t accept external_id. If all you have on hand is your own id, look the product up first with GET /v1/products?external_id=... — see Using your own IDs.

Render the button only when both of these are true:

Field	Required value
tryon_status	"active"
swap_ready	true

A product can be active with swap_ready: false — you enabled try-on before image processing finished. Showing the button in that state opens an empty experience for the customer, so treat both checks as required, not either/or. See Product lifecycle for why these are two independent gates.

In practice this means doing the check wherever you generate product pages — at build time for a static site, at request time for a server-rendered one, or against your own synced copy of the product data if you mirror it locally (see the platform guides below for concrete examples).

Let the panel generate the snippet for you

If you’d rather not hand-assemble the HTML above, the panel’s Install page generates a ready-to-paste snippet — button and script tag, shop_slug and productId already filled in — for each of your active products. Useful for a one-off page, or for confirming your hand-rolled template produces the same markup.

Next

Using your own IDs — mapping PRODUCT_ID to a SKU or database id you already have, so your templates never need to know ours.