This is the full developer documentation for TryOn # TryOn Documentation > Virtual try-on for eyewear, watches, shoes, jewelry, and clothes — one API, one embed script. [Developers](/developers/quickstart/)REST API, storefront embedding, platform guides. [Panel guide](/panel/getting-started/)Manage products, AR fit, previews, team and keys. [Shopify app](/shopify/install/)Install the app, theme blocks, enable try-on. ## Popular guides [Section titled “Popular guides”](#popular-guides) [Storefront integration](/developers/storefront-integration/)Drop the try-on button and bootstrap script onto a product page. [Using your own IDs](/developers/using-your-own-ids/)Map products to your own SKUs or database IDs with external\_id. [Theme extension](/shopify/theme-extension/)Add the try-on block to a Shopify theme in the theme editor. [Managing products](/panel/products/)Create, sync, and configure products from the merchant panel. ## First API call [Section titled “First API call”](#first-api-call) Create a product with a title, category, and image — this also starts the processing that makes it try-on-ready. Create a product ```bash curl -X POST https://api.integration.tryonvirtual.com/v1/products \ -H "Authorization: Bearer tryon_sk_your_key" \ -H "Content-Type: application/json" \ -d '{ "title": "Aviator Sunglasses", "category": "eyewear", "images": ["https://yourstore.com/images/aviator.jpg"] }' ``` See the full walkthrough in the [developer quickstart](/developers/quickstart/). *** Building with an AI agent? Feed it [`/llms.txt`](/llms.txt) or the [OpenAPI spec](https://api.integration.tryonvirtual.com/openapi.yaml). # Authentication > How TryOn API keys work — format, headers, creation, revocation, and safe rotation. Every request to the TryOn API is authenticated with an API key. ## Header format [Section titled “Header format”](#header-format) Send the key as a bearer token on every request: Header ```http Authorization: Bearer tryon_sk_your_key ``` Request ```bash curl https://api.integration.tryonvirtual.com/v1/products \ -H "Authorization: Bearer tryon_sk_your_key" ``` Requests without a valid key get a `401` with the `unauthorized` error code: Response — 401 ```json {"error": {"code": "unauthorized", "message": "Invalid or missing API key"}} ``` ## Creating a key [Section titled “Creating a key”](#creating-a-key) Keys are created and revoked in the [merchant panel](https://panel.tryonvirtual.com), under **Settings → API Keys** — there is no API endpoint for key management, this is deliberately admin-only and UI-only. Only admin users on the shop can create or revoke keys. The full key (`tryon_sk_...`) is shown **once**, at creation time. After that, the panel only ever shows a truncated reference — if you lose the key, revoke it and create a new one. There is no way to retrieve a lost key. ## Limits [Section titled “Limits”](#limits) A shop can have at most **10 active keys** at a time. If you’re at the limit and need a new one, revoke a key you no longer use first. ## Rotating a key [Section titled “Rotating a key”](#rotating-a-key) Because a key is only visible once, rotate before you run out rather than after a key stops working: 1. Create a new key in the panel. 2. Update your integration (env var, secret store, wherever it’s configured) to use the new key. 3. Confirm the new key works — a `200` from any authenticated endpoint (e.g. [`GET /v1/usage`](/api/operations/usage/)) with the new key is enough. `/v1/usage` reports monthly try-on quota — opens, swaps, product counts — not API call volume, so don’t rely on it to see your integration’s traffic; check your own logs for that. 4. Revoke the old key in the panel. Keep both keys active during the switch — there’s no outage window, and you can revoke the old one whenever you’re confident the new one is live. ## Never expose keys client-side [Section titled “Never expose keys client-side”](#never-expose-keys-client-side) The API key is a server-side secret. Never put it in storefront JavaScript, a mobile app bundle, or any code that ships to a browser — treat it like a database password. This isn’t a tradeoff you need to make: the storefront integration never needs a key at all. The [bootstrap script](/developers/product-lifecycle/) that opens the try-on experience on a product page is loaded as a public, unauthenticated URL — all authenticated calls (creating products, adding images, enabling try-on) happen from your backend or build pipeline, not the browser. ## Next [Section titled “Next”](#next) [Product lifecycle](/developers/product-lifecycle/) — the three steps that make a product try-on-ready. # BigCommerce > Add the try-on button and bootstrap script to a Stencil product template, using the product SKU as the identifier. BigCommerce product pages are rendered server-side from Stencil (Handlebars) templates, and the per-product try-on script needs a product identifier at render time — so the reliable place to add both snippets is the product template itself, not a site-wide script. ## Sync products first [Section titled “Sync products first”](#sync-products-first) Same as any platform: create a TryOn product for each BigCommerce product before you can render anything, using the BigCommerce SKU as `external_id` so the two catalogs stay joined: Request ```bash curl -X POST https://api.integration.tryonvirtual.com/v1/products \ -H "Authorization: Bearer tryon_sk_your_key" \ -H "Content-Type: application/json" \ -d '{ "title": "Classic Fit Shirt — Red, XL", "category": "clothes", "external_id": "SHIRT-XL-RED", "images": ["https://cdn11.bigcommerce.com/.../shirt-xl-red.jpg"] }' ``` Pull your catalog from the [BigCommerce Catalog API](https://developer.bigcommerce.com/docs/rest-catalog/products) (`GET /catalog/products`) to loop this over every product, and enable try-on the same way as elsewhere once each one reports `swap_ready: true` — see [Product lifecycle](/developers/product-lifecycle/). See [Using your own IDs](/developers/using-your-own-ids/) for more on the `external_id` mapping. ## Edit the product template [Section titled “Edit the product template”](#edit-the-product-template) In the [Stencil](https://developer.bigcommerce.com/docs/storefront/stencil) theme you’re running, edit the product page template (`templates/pages/product.html`, or the `product-view` component it includes, depending on your theme) and add both snippets where you want the button to appear. `{{product.sku}}` gives you the same value you set as `external_id` during sync: templates/components/products/product-view\.html ```html Try On ``` Edit the template through the [Stencil CLI](https://developer.bigcommerce.com/docs/storefront/stencil/start/setup) (`stencil push` after a local edit) or your theme editor, depending on how your store is set up. Note [Script Manager](https://support.bigcommerce.com/s/article/Using-Script-Manager) (Storefront → Script Manager, no theme access required) is the usual way to add third-party scripts on BigCommerce, but its page-scoping is coarse — *Storefront pages*, *Checkout*, *Order confirmation*, or *All pages* — with no product-page-specific option, and scripts added there are static text with no access to Handlebars variables like `{{product.sku}}`. That makes it a poor fit for a script that needs a different `productId` per product page; the template edit above is the reliable path if you have theme access. ## Only render when ready [Section titled “Only render when ready”](#only-render-when-ready) Check `tryon_status` and `swap_ready` before you decide whether to render the two snippets, same as any other platform — see [Storefront integration](/developers/storefront-integration/#only-render-for-ready-products). If your Stencil template can’t call the TryOn API directly at render time, keep a synced flag (a custom field on the BigCommerce product, or a lookup table on your side) that your sync job updates once a product is both enabled and processed, and branch on that in the template instead of calling out live on every page view. ## Next [Section titled “Next”](#next) [Wix](/developers/wix/) — the same integration where there’s no template to edit, via a Velo custom element. # Custom storefront > The platform-agnostic integration pattern — render decision, templated snippets, and the SPA caveat for client-routed apps. If you’re not on WooCommerce, BigCommerce, or Wix, the integration is the same three pieces described in [Storefront integration](/developers/storefront-integration/) — you just wire them into whatever templating or rendering layer your storefront already uses. ## 1. Decide whether to render, server-side [Section titled “1. Decide whether to render, server-side”](#1-decide-whether-to-render-server-side) Wherever you generate a product page — a template render, a static build step, an API response your frontend consumes — check the product’s current state before deciding whether to include the try-on snippets at all: Request ```bash curl https://api.integration.tryonvirtual.com/v1/products/TRYON_PRODUCT_UUID \ -H "Authorization: Bearer tryon_sk_your_key" ``` `TRYON_PRODUCT_UUID` is the TryOn `id` — REST paths like this one always take that UUID, never your own `external_id` (that works only in the storefront snippet’s `productId` and the `?external_id=` filter — see [Using your own IDs](/developers/using-your-own-ids/)). If your sync job only has its own identifier on hand, look the product up first with `GET /v1/products?external_id=...` to get the `id` this call needs. Render the button only when `tryon_status == "active"` **and** `swap_ready == true`. If you sync TryOn state into your own database rather than calling the API per request (recommended for anything higher-traffic than a handful of pages), keep both fields current there and branch on your local copy instead — see [Product lifecycle](/developers/product-lifecycle/#tryon_status-vs-swap_ready) for why both checks matter independently. ## 2. Template the two snippets with your own id [Section titled “2. Template the two snippets with your own id”](#2-template-the-two-snippets-with-your-own-id) Wire your product identifier — whichever value your system already has, ideally the same one you’re using as `external_id` (see [Using your own IDs](/developers/using-your-own-ids/)) — into both snippets: Your product template ```html Try On ``` (`{{ product.id }}` here is a stand-in for whatever your templating language uses — Jinja, ERB, JSX, a plain string concatenation in a hand-rolled renderer. The two values that matter are your shop slug and the product identifier.) ## 3. Handle client-side routing [Section titled “3. Handle client-side routing”](#3-handle-client-side-routing) The button-binding behavior described in [Storefront integration](/developers/storefront-integration/#how-the-button-binds) runs once, on `DOMContentLoaded`: the bootstrap script scans the page for elements carrying `data-tryon-product-id` at that moment and binds them. That works fine for a traditional multi-page site, where every product page is a fresh document load. It does **not** work for a single-page app that swaps product views via client-side routing without a full page load — the button rendered by your router after the initial load was never scanned, so it won’t be bound. Two ways to handle this in a client-routed app: * **Trigger try-on from your own UI instead of relying on the auto-bound button.** Skip `data-tryon-product-id` entirely and call `window.openTryOn()` from your route/component’s click handler once the bootstrap script for the current product has loaded. * **Re-insert the script tag on every route change**, so a fresh ` ``` Find your shop slug in the panel under **Settings → Shop**. The script ships with the product’s try-on manifest already inlined, so there’s no extra round-trip when a customer clicks the button. Any element with `data-tryon-product-id` binds automatically — you can also call `window.openTryOn()` from your own code. Tip Set `external_id` when you create a product and you can use your own SKU or database id as `PRODUCT_ID` everywhere above instead of ours — see [Product lifecycle](/developers/product-lifecycle/#mapping-to-your-catalog). ## Reference [Section titled “Reference”](#reference) * [API reference](/api/) — full request/response schemas for every endpoint * [Interactive console](/playground/) — try requests against the live API from your browser ## Next [Section titled “Next”](#next) [Authentication](/developers/authentication/) — key format, rotation, and revocation. # Storefront integration > The two-snippet integration that puts the try-on button and bootstrap script on a product page. 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 [Section titled “The two snippets”](#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 ```html Try On ``` `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](/developers/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 [Section titled “How the button binds”](#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 ```html See it on you ``` `window.openTryOn()` opens the same experience the bound button would, using the `productId` the script tag was loaded with. ## Only render for ready products [Section titled “Only render for ready products”](#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 ```bash 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](/developers/using-your-own-ids/#look-products-up-by-it). 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](/developers/product-lifecycle/#tryon_status-vs-swap_ready) 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 [Section titled “Let the panel generate the snippet for you”](#let-the-panel-generate-the-snippet-for-you) If you’d rather not hand-assemble the HTML above, the [panel’s Install page](https://panel.tryonvirtual.com/install) 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 [Section titled “Next”](#next) [Using your own IDs](/developers/using-your-own-ids/) — mapping `PRODUCT_ID` to a SKU or database id you already have, so your templates never need to know ours. # Troubleshooting > Symptoms you'll actually hit integrating the REST API — what each one means, how to confirm it, and how to reach a human. Organized by what you’re seeing, not by what’s wrong. Each entry says how to confirm the cause before you change anything. ## Every request returns `401 unauthorized` [Section titled “Every request returns 401 unauthorized”](#every-request-returns-401-unauthorized) The key is missing, malformed, or revoked. * The header is `Authorization: Bearer tryon_sk_...` — the `Bearer `prefix is required. * Keys are shown once at creation. If you didn’t copy it, you can’t recover it; create a new one in the panel under **Settings → API Keys** and revoke the old one. * A revoked key returns `401`, not `403`. See [Authentication](/developers/authentication/) for the key format and rotation. ## `404 not_found` on a product you know exists [Section titled “404 not\_found on a product you know exists”](#404-not_found-on-a-product-you-know-exists) Two different situations return the same response, deliberately. * **Wrong id type.** REST paths take the TryOn `id` (a UUID). They do not accept `external_id`. If all you have is your own SKU, look it up first with `GET /v1/products?external_id=SKU-1234` — see [Using your own IDs](/developers/using-your-own-ids/#look-products-up-by-it). * **Another shop’s product.** Every request is scoped to the shop that owns the key, and a product belonging to a different shop returns `404` rather than `403`. That is intentional: it never confirms whether a resource exists elsewhere. See [Cross-shop access](/developers/errors-and-limits/#cross-shop-access). ## `swap_ready` never becomes `true` [Section titled “swap\_ready never becomes true”](#swap_ready-never-becomes-true) Processing normally finishes in under a minute. After a few minutes, assume failure rather than slowness. 1. **Check `images_failed`** from the `POST /v1/products` response. A URL that timed out, wasn’t publicly reachable, wasn’t a JPEG/PNG/WebP/GIF, or exceeded 15 MB is reported there and is never silently retried. 2. **Check the product’s `images` array.** If it’s empty, every URL in the batch failed and there is nothing to process. 3. **Confirm the URL is reachable from the public internet.** A URL your own servers can fetch but the public internet can’t — localhost, a private network address, anything behind auth — fails as `unreachable_url`. [Images](/developers/images/#error-codes) lists every per-image code and what it means. ## `400 validation_error` when enabling try-on [Section titled “400 validation\_error when enabling try-on”](#400-validation_error-when-enabling-try-on) Enabling requires a `category` (set at create time, and it can’t be left unset later) and a `mode`. The common case is `mode: realtime`, which additionally requires an active 3D asset and returns `400 validation_error` with “Active 3D asset required for real-time mode” when none is usable. 3D assets are managed in the [panel](https://panel.tryonvirtual.com) — this API can’t attach one. `mode: swap` is the only mode you can drive end-to-end through the API. Also note that changing `mode` on a product that already has try-on enabled turns it off again; send a fresh `tryon_enabled: true` afterward. See [Product lifecycle](/developers/product-lifecycle/#mode-realtime-vs-swap). ## Try-on is on, but the button does nothing [Section titled “Try-on is on, but the button does nothing”](#try-on-is-on-but-the-button-does-nothing) Work down this list in order: * **Both gates satisfied?** `tryon_status` must be `"active"` **and** `swap_ready` must be `true`. A product can be active with `swap_ready: false` — the button opens an empty experience. See [tryon\_status vs. swap\_ready](/developers/product-lifecycle/#tryon_status-vs-swap_ready). * **Is the bootstrap script actually on the page?** The button is inert on its own; it only binds because the script is present. * **Does the script’s `productId` match the button’s `data-tryon-product-id`?** They have to be the same product. * **Is `shop_slug` correct?** Find it in the panel under **Settings → Shop**. One thing that catches people: the bootstrap script is served from `widget.tryonvirtual.com/api/v1/tryon/scripts/embed/bootstrap.js`, not from the `/v1/...` public API namespace on `api.integration.tryonvirtual.com` that the rest of these docs use. **Different host and different path** — the bootstrap lives on the widget host so it shares an origin with the widget bundle it loads next, which saves the browser a second TLS handshake mid-click. Copy the URL from [Storefront integration](/developers/storefront-integration/) exactly rather than reconstructing it from the REST base. ## Only one product opens on a page with several [Section titled “Only one product opens on a page with several”](#only-one-product-opens-on-a-page-with-several) Expected, and it’s a hard limit rather than a bug. Every bootstrap script defines the same `window.openTryOn` global, so a second script on the same page **overwrites** the first instead of adding a product. For grids, quick-view cards, and bundle pages, link each product to its own product page. See [The two snippets](/developers/storefront-integration/#the-two-snippets). ## `429 rate_limited` during a bulk import [Section titled “429 rate\_limited during a bulk import”](#429-rate_limited-during-a-bulk-import) The limit is 120 requests per minute per API key. The response carries a `Retry-After` header in seconds — wait at least that long before retrying, and space out a catalog import rather than firing it all at once. See [Rate limits](/developers/errors-and-limits/#rate-limits). ## Still stuck? [Section titled “Still stuck?”](#still-stuck) Open the support chat in the [merchant panel](https://panel.tryonvirtual.com) — the bubble in the bottom corner reaches the team directly. Include the product `id`, the endpoint you called, and the `code` from the error envelope; all three make it answerable on the first reply. # Using your own IDs > Map TryOn products to your own SKUs or database ids with external_id, so your templates never store ours. By default, every product you create gets an `id` we generate — a UUID you’d need to store somewhere in your own system to look the product back up later, or to fill in `PRODUCT_ID` in the [storefront snippet](/developers/storefront-integration/). `external_id` lets you skip that: set it to whatever you already use to identify the product — a SKU, a database primary key — and use that value as the storefront `productId` and to look products up, instead of storing our `id`. Note `external_id` is **not** a substitute for `id` in REST paths. `GET/PATCH/DELETE /v1/products/{id}` always takes the TryOn `id` (a UUID) — `PATCH /v1/products/SHIRT-XL-RED` returns `404`, it never reaches the product. `external_id` works in exactly two places: the storefront snippet’s `productId`, and the `GET /v1/products?external_id=...` filter. See [Look products up by it](#look-products-up-by-it) below for the lookup-then-act pattern this implies for any endpoint that isn’t `POST /v1/products`. ## Set it at create time [Section titled “Set it at create time”](#set-it-at-create-time) Request ```bash curl -X POST https://api.integration.tryonvirtual.com/v1/products \ -H "Authorization: Bearer tryon_sk_your_key" \ -H "Content-Type: application/json" \ -d '{ "title": "Classic Fit Shirt — Red, XL", "category": "clothes", "external_id": "SHIRT-XL-RED" }' ``` Response ```json { "product": { "id": "7a2b9c1d-3e4f-4a5b-8c6d-1234567890ab", "external_id": "SHIRT-XL-RED", "title": "Classic Fit Shirt — Red, XL", "category": "clothes", "tryon_status": "inactive", "swap_ready": false, "...": "..." }, "images_failed": [] } ``` You still get an `id` back — that never goes away — but from here on you can ignore it and work entirely in terms of `SHIRT-XL-RED`. ## Or set it later with PATCH [Section titled “Or set it later with PATCH”](#or-set-it-later-with-patch) If a product already exists and you’re backfilling `external_id` for it (migrating from a system that only had our `id`, for example), `PATCH` works the same way: Request ```bash curl -X PATCH https://api.integration.tryonvirtual.com/v1/products/7a2b9c1d-3e4f-4a5b-8c6d-1234567890ab \ -H "Authorization: Bearer tryon_sk_your_key" \ -H "Content-Type: application/json" \ -d '{"external_id": "SHIRT-XL-RED"}' ``` ## It’s unique per shop [Section titled “It’s unique per shop”](#its-unique-per-shop) `external_id` only has to be unique within your own shop — two different shops can each use `SHIRT-XL-RED` for unrelated products. Trying to set an `external_id` that’s already in use on another product in your shop returns `400 validation_error`. ## Look products up by it [Section titled “Look products up by it”](#look-products-up-by-it) Request ```bash curl "https://api.integration.tryonvirtual.com/v1/products?external_id=SHIRT-XL-RED" \ -H "Authorization: Bearer tryon_sk_your_key" ``` This is the read side of the same mapping — useful for a sync job that needs to check “does this SKU already exist as a TryOn product?” before deciding whether to `POST` or `PATCH`. It’s also how you act on a product when all you have is its `external_id`: look it up, take the `id` from the result, then use that `id` in the path of any endpoint that isn’t `POST /v1/products`. For example, enabling try-on for `SHIRT-XL-RED`: Look up, then act ```bash # 1. Look up the TryOn id for your external_id PRODUCT_ID=$(curl -s "https://api.integration.tryonvirtual.com/v1/products?external_id=SHIRT-XL-RED" \ -H "Authorization: Bearer tryon_sk_your_key" | jq -r '.products[0].id') # 2. Use that id — not the external_id — in the PATCH path curl -X PATCH "https://api.integration.tryonvirtual.com/v1/products/$PRODUCT_ID" \ -H "Authorization: Bearer tryon_sk_your_key" \ -H "Content-Type: application/json" \ -d '{"mode": "swap", "tryon_enabled": true}' ``` ## Use it as PRODUCT\_ID directly [Section titled “Use it as PRODUCT\_ID directly”](#use-it-as-product_id-directly) Once `external_id` is set, drop it straight into the storefront snippet in place of our `id`: Your product page ```html Try On ``` This is the one place `external_id` is a full drop-in for `id` — the embed script and the button’s `data-tryon-product-id` both accept either value interchangeably. Combined with the `?external_id=` filter for lookups, most integrations that manage their own catalog find they never need to store our `id` in a template at all — only in the occasional server-side call that needs the lookup step above. ## Not available on Shopify-platform shops [Section titled “Not available on Shopify-platform shops”](#not-available-on-shopify-platform-shops) `external_id` is read-only for shops on the Shopify platform: `PATCH` requests that try to set it are rejected with `400 validation_error`. On Shopify, that mapping is already owned by the Shopify sync — every TryOn product created from a Shopify sync carries the Shopify product id internally, and introducing a second, independently-set external id would create two competing sources of truth for the same mapping. This API’s `external_id` field exists for WooCommerce, custom platforms, and any other non-Shopify shop that needs to bring its own identifiers. ## Next [Section titled “Next”](#next) [WooCommerce](/developers/woocommerce/) — a worked integration using the Woo product SKU as `external_id`. # Wix > Sync your Wix Stores catalog to TryOn and render the try-on button on the product page with a Velo custom element. Wix gives you no server-side product template to edit, so the two snippets from [Storefront integration](/developers/storefront-integration/) can’t be pasted in as static HTML — every product page is the same page, and the bootstrap script needs a different `productId` on each one. The path that works is [Velo](https://dev.wix.com/docs/velo): a **custom element** that renders the button in the page’s own DOM, and page code that tells it which product it’s showing. Note Steps 2–4 need Dev Mode turned on for the site (Wix Editor → **Dev Mode** → **Turn on Dev Mode**). The catalog sync in step 1 runs entirely outside Wix and doesn’t. ## 1. Sync products, using a Wix identifier as external\_id [Section titled “1. Sync products, using a Wix identifier as external\_id”](#1-sync-products-using-a-wix-identifier-as-external_id) Read your catalog with Wix Stores’ [Query Products](https://dev.wix.com/docs/api-reference/business-solutions/stores/catalog-v3/products-v3/query-products), then create a matching TryOn product for each one. Wix REST calls authenticate with an API key from the [API Keys Manager](https://manage.wix.com/account/api-keys) plus your site id — note the key goes in `Authorization` bare, with no `Bearer` prefix, unlike TryOn’s: Read the Wix catalog ```bash curl -X POST https://www.wixapis.com/stores/v3/products/query \ -H "Authorization: WIX_API_KEY" \ -H "wix-site-id: WIX_SITE_ID" \ -H "Content-Type: application/json" \ -d '{"query": {"filter": {"visible": {"$eq": true}}, "cursorPaging": {"limit": 100}}}' ``` Create the TryOn product ```bash curl -X POST https://api.integration.tryonvirtual.com/v1/products \ -H "Authorization: Bearer tryon_sk_your_key" \ -H "Content-Type: application/json" \ -d '{ "title": "Classic Fit Shirt — Red, XL", "category": "clothes", "external_id": "SHIRT-XL-RED", "images": ["https://static.wixstatic.com/media/shirt-xl-red.jpg"] }' ``` [category](/developers/product-lifecycle/#1-create-it-with-a-category) is required and drives which AI model processes the product — map it from your Wix collections or product type, it won’t come across automatically. Once images finish processing and `swap_ready` turns `true`, `PATCH` the product to enable try-on exactly as on any other platform; see [Product lifecycle](/developers/product-lifecycle/) for both calls. For a one-time load you don’t have to script against the Wix API at all — export the catalog to CSV from the store dashboard and feed it through the bulk sync loop on the [WooCommerce page](/developers/woocommerce/#1-sync-products-using-the-woo-sku-as-external_id). ### Choosing the identifier [Section titled “Choosing the identifier”](#choosing-the-identifier) Whatever you store as `external_id` has to be a value the product page can read back in step 4. Velo’s `getProduct()` hands you both `sku` and `_id`, so either works — with one wrinkle: in the V3 catalog, SKUs are a variant field, and Query Products [doesn’t return variant data](https://dev.wix.com/docs/api-reference/business-solutions/stores/catalog-v3/products-v3/query-products), so syncing by SKU means an extra per-product call to read it. Syncing by the Wix product id avoids that. Either way the invariant is the same: the value you store as `external_id` must be the exact value your page code reads back. See [Using your own IDs](/developers/using-your-own-ids/). ## 2. Add a custom element [Section titled “2. Add a custom element”](#2-add-a-custom-element) public/custom-elements/tryon-button.js ```js const SHOP_SLUG = 'YOUR_SHOP_SLUG'; class TryOnButton extends HTMLElement { static get observedAttributes() { return ['product-id']; } attributeChangedCallback(name, previous, productId) { if (name !== 'product-id' || !productId || productId === previous) return; this.render(productId); } render(productId) { // No shadow root on purpose — the button and the bootstrap script both // belong in the page's own DOM. this.innerHTML = ''; const button = document.createElement('button'); button.type = 'button'; button.textContent = 'Try On'; button.disabled = true; // until the bootstrap script has loaded button.addEventListener('click', () => window.openTryOn()); this.appendChild(button); // One bootstrap script per product. Wix moves between products without a // full page load, so drop the previous one before loading the next. this.script?.remove(); const script = document.createElement('script'); script.async = true; script.src = 'https://widget.tryonvirtual.com/api/v1/tryon/scripts/embed/bootstrap.js' + `?shop_slug=${SHOP_SLUG}&productId=${encodeURIComponent(productId)}`; script.onload = () => { button.disabled = false; }; this.script = script; document.head.appendChild(script); } } customElements.define('tryon-button', TryOnButton); ``` Find `YOUR_SHOP_SLUG` in the panel under **Settings → Shop**. Add it to the product page from the editor — **Add Elements → Embed → Popular Embeds → Custom Element** in the Wix Editor, **Add Elements → Embed & Social → Custom Element** in Wix Studio — then **Choose Source → Velo file**, pick the file, and enter `tryon-button` as the **Tag Name**. It has to match the string in `customElements.define()` exactly. (Wix’s own walkthrough is [Add a Custom Element](https://dev.wix.com/docs/velo/velo-only-apis/$w/custom-element/add-a-custom-element).) Two details in that code are deliberate: * **The click handler calls `window.openTryOn()` instead of using `data-tryon-product-id`.** The automatic binding described in [Storefront integration](/developers/storefront-integration/#how-the-button-binds) scans the page once, on `DOMContentLoaded`. This element renders later — after Velo has fetched the product and set the attribute — so its button was never scanned and would never be bound. Calling the global directly is the documented way out, the same one a client-routed app needs (see [Custom storefront](/developers/custom-storefront/#3-handle-client-side-routing)). * **The old script tag is removed before a new one is added.** Every bootstrap script defines the same `window.openTryOn` global, so a page carrying two of them offers try-on for whichever loaded last, not for both — try-on is [one product per page](/developers/storefront-integration/#the-two-snippets). Note Wix’s [Custom Code panel](https://support.wix.com/en/article/embedding-custom-code-on-your-site) (dashboard → **Settings → Custom Code**) can scope a script to the product page, which makes it look like the obvious home for the bootstrap tag. It isn’t: the code it injects is static text with no access to the current product, and the bootstrap script needs a per-product `productId`. The custom element exists precisely because Velo can set its attributes per product. ## 3. Keep the API key in the backend [Section titled “3. Keep the API key in the backend”](#3-keep-the-api-key-in-the-backend) Page code and the custom element both run in the visitor’s browser, so an API key put in either one is public — and a `tryon_sk_` key can create and modify every product in your shop. Store it in the Wix **Secrets Manager** (dashboard → **Settings → Secrets Manager**) and do the readiness check in a backend web module instead: backend/tryon.web.js ```js import { Permissions, webMethod } from 'wix-web-module'; import { getSecret } from 'wix-secrets-backend'; import { fetch } from 'wix-fetch'; export const isTryOnReady = webMethod(Permissions.Anyone, async (externalId) => { const apiKey = await getSecret('tryon_api_key'); const response = await fetch( 'https://api.integration.tryonvirtual.com/v1/products' + `?external_id=${encodeURIComponent(externalId)}`, { headers: { Authorization: `Bearer ${apiKey}` } } ); if (!response.ok) return false; const { products } = await response.json(); const product = products?.[0]; // Both gates, not either/or — see Storefront integration. return Boolean(product && product.tryon_status === 'active' && product.swap_ready); }); ``` The lookup goes through `?external_id=` rather than `/v1/products/{id}` because the value the page has on hand is your identifier, not TryOn’s UUID — REST paths only ever take the UUID ([Using your own IDs](/developers/using-your-own-ids/#look-products-up-by-it)). And both fields are checked because a product can be `active` with `swap_ready: false`, which opens an empty experience for the customer — [why both gates matter](/developers/product-lifecycle/#tryon_status-vs-swap_ready). As written this calls the TryOn API on every product page view, which is fine for a small catalog. For anything busier, mirror `tryon_status` and `swap_ready` into a Wix Data collection from a scheduled sync job and have this function read that instead — same reasoning as [Storefront integration](/developers/storefront-integration/#only-render-for-ready-products). ## 4. Wire the product page [Section titled “4. Wire the product page”](#4-wire-the-product-page) In Dev Mode, open the **Product Page** and add its page code: Product Page — page code ```js import { isTryOnReady } from 'backend/tryon.web'; $w.onReady(async () => { const product = await $w('#productPage1').getProduct(); const externalId = product.sku; // the value you stored as external_id in step 1 if (!externalId) return; if (!(await isTryOnReady(externalId))) return; // The element renders nothing until it receives this attribute, so a product // that isn't ready simply never shows a button. $w('#customElement1').setAttribute('product-id', externalId); }); ``` `#productPage1` and `#customElement1` are Wix’s default element ids — confirm both in the editor’s Properties panel, since a page with more than one of either will number them differently. Because the readiness check gates the `setAttribute()` call, there’s no separate “only render when ready” step here: an unready product never gets a `product-id`, and the element renders nothing. ## Don’t use the HTML embed [Section titled “Don’t use the HTML embed”](#dont-use-the-html-embed) Wix’s **Embed HTML** element looks like a shortcut for pasting the two snippets, but it renders its contents inside a cross-origin sandboxed iframe, which breaks try-on twice over. The experience is confined to the embed box instead of covering the page, and webcam AR needs the iframe to carry `allow="camera"` — a Permissions Policy delegation the parent page has to grant, which the Wix editor gives you no way to set. The custom element above has neither problem: it runs in the page’s own document. ## Next [Section titled “Next”](#next) [Custom storefront](/developers/custom-storefront/) — the platform-agnostic version of the same integration, plus notes for single-page apps. # WooCommerce > Create TryOn products from your WooCommerce catalog and render the try-on button on the single product page. There’s no WooCommerce plugin — this is a plain REST integration using the TryOn API and a small `functions.php` snippet. Two pieces: a sync step that creates a TryOn product for each WooCommerce product (using the Woo SKU as `external_id`), and a template hook that renders the button. Note This assumes your theme (or child theme) supports a `functions.php` you can edit. If you’re on a page builder without template access, see [Custom storefront](/developers/custom-storefront/) for the platform-agnostic version of the same idea. ## 1. Sync products, using the Woo SKU as external\_id [Section titled “1. Sync products, using the Woo SKU as external\_id”](#1-sync-products-using-the-woo-sku-as-external_id) Loop over your WooCommerce catalog via the [Woo REST API](https://woocommerce.github.io/woocommerce-rest-api-docs/) and create a matching TryOn product for each one, passing the SKU as `external_id` so the two systems stay joined without you having to store TryOn’s own `id` anywhere: Note `TRYON_API_KEY` below is a constant you define in `wp-config.php` — `define('TRYON_API_KEY', 'tryon_sk_your_key');` — not a value to hardcode inline. Keep `wp-config.php` out of version control (it usually already is by default) since this key can create and modify products in your shop. Sync products to TryOn ```php -1, 'status' => 'publish']); foreach ($products as $product) { $sku = $product->get_sku(); if (!$sku) { continue; // external_id needs something stable — skip products without a SKU } $response = wp_remote_post('https://api.integration.tryonvirtual.com/v1/products', [ 'headers' => [ 'Authorization' => 'Bearer ' . TRYON_API_KEY, 'Content-Type' => 'application/json', ], 'body' => wp_json_encode([ 'title' => $product->get_name(), 'category' => 'clothes', // map from your product categories/attributes 'external_id' => $sku, 'images' => [wp_get_attachment_url($product->get_image_id())], ]), ]); // Store a local flag so the template hook below doesn't need a live API // call on every page view — see step 3. if (!is_wp_error($response) && wp_remote_retrieve_response_code($response) === 201) { update_post_meta($product->get_id(), '_tryon_synced', '1'); } } ``` Equivalent as a plain curl loop, if you’re driving this from outside WordPress against a Woo export instead: Bulk sync from an export ```bash # products.json: [{"sku": "SHIRT-XL-RED", "title": "...", "category": "clothes", "image": "..."}] jq -c '.[]' products.json | while read -r p; do curl -X POST https://api.integration.tryonvirtual.com/v1/products \ -H "Authorization: Bearer tryon_sk_your_key" \ -H "Content-Type: application/json" \ -d "$(echo "$p" | jq '{title, category, external_id: .sku, images: [.image]}')" done ``` Either way, [category](/developers/product-lifecycle/#1-create-it-with-a-category) is required and drives which AI model processes the product — map it from your Woo product categories or attributes, it won’t come from Woo automatically. ## 2. Enable try-on once images finish processing [Section titled “2. Enable try-on once images finish processing”](#2-enable-try-on-once-images-finish-processing) Same as any other integration — poll or re-check the product until `swap_ready` is `true`, then `PATCH` to turn it on. The `PATCH` path needs the TryOn `id` (a UUID), not the SKU — `external_id` only works as a query filter or in the storefront snippet, never in a REST path (see [Using your own IDs](/developers/using-your-own-ids/)). If your sync job already has the `id` from the create response in step 1, use that directly; otherwise look it up by SKU first: Enable try-on ```bash # If you only have the SKU: look up the id, then PATCH with it PRODUCT_ID=$(curl -s "https://api.integration.tryonvirtual.com/v1/products?external_id=SHIRT-XL-RED" \ -H "Authorization: Bearer tryon_sk_your_key" | jq -r '.products[0].id') curl -X PATCH "https://api.integration.tryonvirtual.com/v1/products/$PRODUCT_ID" \ -H "Authorization: Bearer tryon_sk_your_key" \ -H "Content-Type: application/json" \ -d '{"mode": "swap", "tryon_enabled": true}' ``` In the PHP loop from step 1, skip the lookup entirely — decode the create response and reuse the `id` it already gave you: Store the TryOn id ```php $body = json_decode(wp_remote_retrieve_body($response), true); $tryon_id = $body['product']['id'] ?? null; if ($tryon_id) { wp_remote_request("https://api.integration.tryonvirtual.com/v1/products/{$tryon_id}", [ 'method' => 'PATCH', 'headers' => [ 'Authorization' => 'Bearer ' . TRYON_API_KEY, 'Content-Type' => 'application/json', ], 'body' => wp_json_encode(['mode' => 'swap', 'tryon_enabled' => true]), ]); } ``` `swap_ready` still needs a moment to flip to `true` after images are added — enabling try-on early is fine (see [Product lifecycle](/developers/product-lifecycle/#tryon_status-vs-swap_ready)), just don’t render the button until the render check in step 3 confirms both are true. ## 3. Render the button on the single product page [Section titled “3. Render the button on the single product page”](#3-render-the-button-on-the-single-product-page) Hook into `woocommerce_single_product_summary` and use `$product->get_sku()` as the `productId` — the same value you set as `external_id` during sync: functions.php ```php get_sku(); if (!$sku) { return; } // Don't call the TryOn API on every page load — check the flag you cached // during sync instead (see step 1). If you need it fresher than your sync // cadence, cache the API response in a transient rather than checking live. if (get_post_meta($product->get_id(), '_tryon_synced', true) !== '1') { return; } ?> Try On Use the AR Fit Editor's live webcam preview to adjust how a 3D model sits on a customer, then save the fit. Real-time AR models are generated (or uploaded) with a reasonable default fit, but eyewear and watches sit differently on every face and wrist. The AR Fit Editor lets you nudge the model until it looks right, watching it live on your own camera as you adjust it. ## Opening the editor [Section titled “Opening the editor”](#opening-the-editor) On a product’s **3D Assets** list, any eligible asset has an **AR Fit** button that opens the editor at `/products/:productId/ar-fit/:assetId`. It’s only available for AR-capable assets (eyewear and watch GLB models, and eyewear assembly models). ## What it adjusts [Section titled “What it adjusts”](#what-it-adjusts) The editor exposes position, rotation, and scale for the model, with scrubable number inputs so you can drag a value up or down instead of typing exact numbers. Changes apply instantly to the live preview. ## Live webcam preview [Section titled “Live webcam preview”](#live-webcam-preview) The editor opens your camera and overlays the model on you in real time, the same way a customer would see it in AR try-on. This is the fastest way to tell whether a fit is actually right — static screenshots can be misleading. ## Saving [Section titled “Saving”](#saving) Adjustments aren’t saved until you click **Save**. If you change your mind, **Discard** reverts to the last saved configuration. The save button is disabled until something has actually changed, so you can’t accidentally save a no-op. ## Next [Section titled “Next”](#next) [Widget & preview](/panel/widget-preview/) — see the finished try-on experience on an actual product page before it goes live for customers. # Billing > Where to see your usage against plan limits, what counts toward it, and how to upgrade from the Billing page. ## Plans [Section titled “Plans”](#plans) Plan tiers and what each one includes live on the [pricing page](https://tryonvirtual.com/pricing) — the panel doesn’t duplicate that list, it just shows you where you stand against whichever plan you’re on. ## What counts as usage [Section titled “What counts as usage”](#what-counts-as-usage) Your plan carries four limits, and they meter different things: * **Try-on opens** — counted per *unique shopper per month*, not per open. The same shopper opening try-on repeatedly across a month counts once. * **AI Swaps** — counted per generation *started*, including ones that fail during processing. * **3D generations** — every 3D model you generate from product photos. * **Products** — how many products can have try-on enabled at once. This is an ongoing ceiling, not a monthly allowance; deactivating a product frees the slot immediately. Try-ons you run yourself from the preview aren’t metered — only real shopper sessions on your storefront count. [Measuring results](/panel/measuring-results/) explains why the dashboard’s **Try-on Sessions** number is higher than your metered usage — it counts a different thing. ## Where to see it [Section titled “Where to see it”](#where-to-see-it) The **Billing** page shows a **Quota Usage** card with a progress bar for each of these, current usage against your limit for the billing period. Bars shift color as you approach the limit, so it’s easy to see at a glance if you’re getting close. ## What happens when you go over [Section titled “What happens when you go over”](#what-happens-when-you-go-over) Try-on keeps working. Limits are soft by default — shoppers aren’t turned away the moment you cross a threshold, and the widget doesn’t switch off mid-month. **On Shopify-billed paid plans, extra usage is pay-as-you-go.** Two of the four meters bill past their limit: **try-on sessions** (charged per extra session) and **3D generations** (charged per extra model). Each plan has its own per-unit rates, listed with the plan on the [pricing page](https://tryonvirtual.com/pricing) and on the plan cards in your Shopify admin. Those charges go through Shopify’s Billing API and are capped per billing cycle, so there’s a ceiling on what an unexpectedly busy month can cost, and you’ll see a notification as you approach that cap. **The free plan has no overage at all.** Usage simply pauses at the limit until the next cycle — nothing is ever billed on it. Stores that persistently run far past their limits can be switched to hard enforcement, where shoppers are refused once the limit is reached. That’s applied manually and only in cases of sustained overuse. ## Changing your plan [Section titled “Changing your plan”](#changing-your-plan) The **Plans & Pricing** section on the same page lists every available plan. What the button does depends on where you’re starting from. **Your first paid plan.** If you don’t have a subscription yet, choosing a plan opens a hosted checkout. Once payment goes through, your new limits apply right away and you’ll see a confirmation on the page. **Moving up.** On a more expensive plan than your current one, **Upgrade** takes effect immediately — no checkout, since your card is already on file. You’re invoiced a prorated amount for the rest of the current period, and the higher limits apply straight away. **Moving down.** On a cheaper plan, **Downgrade** is scheduled rather than immediate: you keep your current plan and its limits until the end of the billing period you’ve already paid for, and the new plan starts at your next renewal. The page asks you to confirm before scheduling it. **Changing your mind.** While a downgrade is scheduled, the Billing page shows which plan you’re moving to and when. Your current plan’s card offers **Keep this plan**, which cancels the scheduled downgrade and leaves you where you are. Usage counters aren’t reset by a plan change — they keep running for the calendar month, and the new plan’s limits simply apply to the same numbers. Two things to know: * **Moving to the free plan isn’t a downgrade** — use **Cancel subscription** instead. Your access continues until the end of the period you’ve paid for. * **You can’t switch plans while a cancellation is pending.** Reactivate first, or wait for the period to end and subscribe again. Only admins and members with the Billing role can manage billing — see [Team & API keys](/panel/team-and-api-keys/) for role details. If your shop is on Shopify, billing is instead managed through your Shopify admin, and plan changes there take effect immediately rather than at the next renewal. ## Next [Section titled “Next”](#next) Ready to automate? The [developer quickstart](/developers/quickstart/) walks through creating products and enabling try-on with the REST API. # Driving try-on usage > Where to place the try-on button on your storefront, what to label it, and how to link campaigns straight into an open try-on experience. A working install still goes unused if shoppers never notice the button. Because you control your storefront’s markup directly, placement is entirely yours to choose — here’s what to aim for. ## Put the button next to Add to Cart [Section titled “Put the button next to Add to Cart”](#put-the-button-next-to-add-to-cart) Place the element carrying `data-tryon-product-id` directly beside or below your **Add to Cart** button, above the fold. Shoppers are already looking there when they’re deciding, and it doesn’t ask them to go hunting. Any element with that attribute is bound automatically — it doesn’t have to be a ``. See [Storefront integration](/developers/storefront-integration/) for the binding rules and the `window.openTryOn()` call if you’d rather trigger it from your own UI. ## Check mobile separately [Section titled “Check mobile separately”](#check-mobile-separately) Product templates usually stack differently on narrow viewports, so a button that sits above the fold on desktop can end up several scrolls down on a phone. Load a product page on a real device and confirm the button is still near Add to Cart. ## Write a label that says what happens [Section titled “Write a label that says what happens”](#write-a-label-that-says-what-happens) Keep it short and action-led — “See it on you” or “Try it on” — so it’s obvious what clicking it does. Since you own the markup, the button inherits your own styles; make sure it reads as a primary action rather than a secondary link. ## Start with your highest-traffic products [Section titled “Start with your highest-traffic products”](#start-with-your-highest-traffic-products) The **Install Widget** page lists a snippet per active product, so you can roll out gradually. Start with the products that already get the most visits — you’ll get readable numbers from them fastest, which tells you whether your placement works before you go wider. ## Link campaigns straight into try-on [Section titled “Link campaigns straight into try-on”](#link-campaigns-straight-into-try-on) The **Advanced** section of the **Install Widget** page includes a URL parameter that auto-opens try-on on page load. That turns any email, ad, or QR code into a direct link to the try-on experience rather than to a product page the shopper still has to act on. Use it for campaign traffic specifically — leaving it on for organic traffic means every visitor gets the modal whether they asked for it or not. ## Show related products inside the modal [Section titled “Show related products inside the modal”](#show-related-products-inside-the-modal) Also under **Advanced**: an option to show related products inside the try-on modal, so a shopper who opens try-on for one frame can move through several without going back to your listing pages. Worth turning on if your catalog has close variants. ## Next [Section titled “Next”](#next) [Measuring results](/panel/measuring-results/) — the dashboard metrics and funnels, and what each one counts. # FAQ > Answers to the questions merchants ask most about setting up, promoting, measuring, and billing virtual try-on from the panel. Quick answers with links to the full guides. New here? Start at [Getting started](/panel/getting-started/). ## Getting started [Section titled “Getting started”](#getting-started) ### How do I turn on try-on for a product? [Section titled “How do I turn on try-on for a product?”](#how-do-i-turn-on-try-on-for-a-product) Create the product, set its category, upload photos, then choose a try-on mode on the product page — AI Swap works immediately, real-time AR needs a 3D model first. The **Try-on Status** card has the on/off toggle. See [Products](/panel/products/). ### Why isn’t the try-on button showing on my storefront? [Section titled “Why isn’t the try-on button showing on my storefront?”](#why-isnt-the-try-on-button-showing-on-my-storefront) Check that the product is enabled in the panel, that both snippets are on the page (the button element *and* that product’s bootstrap script), and that the script’s `shop_slug` and product ID are correct. [Storefront integration](/developers/storefront-integration/) covers the binding rules. ### Do I need a developer to install try-on? [Section titled “Do I need a developer to install try-on?”](#do-i-need-a-developer-to-install-try-on) You need someone who can paste two snippets into your product template. That’s usually a theme-level edit rather than a development project, but unlike the Shopify app there’s no click-to-install block — you’re adding markup to your own storefront. ### How do I preview try-on before it goes live? [Section titled “How do I preview try-on before it goes live?”](#how-do-i-preview-try-on-before-it-goes-live) Every product detail page has a **Preview** button that opens the widget exactly as a customer would see it, using a short-lived scoped link. Preview doesn’t count against your plan — see [Widget & preview](/panel/widget-preview/). ### How do I turn try-on off or remove the button? [Section titled “How do I turn try-on off or remove the button?”](#how-do-i-turn-try-on-off-or-remove-the-button) Toggle try-on off on the product page to pause it while keeping your setup, or remove the snippets from your template to take the button off the page entirely. Toggling off affects one product; removing the button snippet affects every page it’s on. ## Driving try-on usage [Section titled “Driving try-on usage”](#driving-try-on-usage) ### Where should I place the try-on button so shoppers notice it? [Section titled “Where should I place the try-on button so shoppers notice it?”](#where-should-i-place-the-try-on-button-so-shoppers-notice-it) Directly beside or below **Add to Cart**, above the fold. See [Driving try-on usage](/panel/driving-usage/). ### Can I promote try-on in emails, banners, or campaigns? [Section titled “Can I promote try-on in emails, banners, or campaigns?”](#can-i-promote-try-on-in-emails-banners-or-campaigns) Yes — and you can do better than linking to the product page. The **Install Widget** page’s **Advanced** section has a URL parameter that auto-opens try-on on load, so campaign traffic lands directly in the experience. ### What should the try-on button say? [Section titled “What should the try-on button say?”](#what-should-the-try-on-button-say) Something short and action-led like “See it on you”. Since you own the markup, also make sure it reads visually as a primary action rather than a secondary link. ### Why aren’t my customers using try-on? [Section titled “Why aren’t my customers using try-on?”](#why-arent-my-customers-using-try-on) Usually placement — the button is below where shoppers stop scrolling, or styled so it reads as a minor link. Check a real mobile device as well as desktop, since templates stack differently on narrow viewports. ### How do I get more shoppers to use try-on? [Section titled “How do I get more shoppers to use try-on?”](#how-do-i-get-more-shoppers-to-use-try-on) Move the button next to Add to Cart, enable it on your highest-traffic products first, and point campaign links at the auto-open URL parameter rather than the plain product page. ### Which products should I turn on first? [Section titled “Which products should I turn on first?”](#which-products-should-i-turn-on-first) Your highest-traffic items. They’ll give you readable funnel data fastest, which tells you whether your placement works before you roll out further. ### Does button placement differ on mobile vs desktop? [Section titled “Does button placement differ on mobile vs desktop?”](#does-button-placement-differ-on-mobile-vs-desktop) The widget adapts, but your template probably doesn’t stack the same way. Load a product page on a real phone and confirm the button is still near Add to Cart. ## 3D models and methods [Section titled “3D models and methods”](#3d-models-and-methods) ### What’s the difference between real-time AR and AI Swap? [Section titled “What’s the difference between real-time AR and AI Swap?”](#whats-the-difference-between-real-time-ar-and-ai-swap) Real-time AR renders a 3D model live on the shopper through their camera. AI Swap generates a photorealistic image of the product on a photo the shopper provides. See [Products](/panel/products/). ### Which product categories work best with real-time AR vs AI Swap? [Section titled “Which product categories work best with real-time AR vs AI Swap?”](#which-product-categories-work-best-with-real-time-ar-vs-ai-swap) Real-time AR is only available for **eyewear and watches**. All seven categories work with AI Swap, including everything soft or draping. ### How do I get the highest-quality 3D result? [Section titled “How do I get the highest-quality 3D result?”](#how-do-i-get-the-highest-quality-3d-result) Use sharp, evenly lit photos on a plain background showing several angles, with no other objects in frame. Once the asset is analyzed you’ll get a quality grade and a report explaining it. ### How do I create a 3D model for eyewear? [Section titled “How do I create a 3D model for eyewear?”](#how-do-i-create-a-3d-model-for-eyewear) On the product page, generate from photos — pick up to four of the product’s images and the model is built automatically. Clear front and side shots of the frames matter most. ### What product photos give the best generation results? [Section titled “What product photos give the best generation results?”](#what-product-photos-give-the-best-generation-results) Sharp, evenly lit, plain background, multiple angles, no props or extra objects. Heavy shadows and busy backgrounds are the two most common causes of a poor grade. ### My generated model looks wrong — how do I fix or redo it? [Section titled “My generated model looks wrong — how do I fix or redo it?”](#my-generated-model-looks-wrong--how-do-i-fix-or-redo-it) If the *fit* is off, use the [AR Fit Editor](/panel/ar-fit-editor/) to correct position, rotation, and scale against a live camera preview. If the *model itself* is wrong, open its quality report, then regenerate with better photos or request optimization. ### What do I do if 3D generation fails? [Section titled “What do I do if 3D generation fails?”](#what-do-i-do-if-3d-generation-fails) An asset that comes back `failed` almost always had no usable input photo. Try again with cleaner, higher-resolution images on a plain background, or upload your own model instead. ### How do I upload my own 3D model? [Section titled “How do I upload my own 3D model?”](#how-do-i-upload-my-own-3d-model) On the product page, upload a GLB, GLTF, USDZ, SPZ, or PLY file up to 20MB. It runs through `uploaded → analyzing → analyzed`, then use the AR Fit Editor to position it and make it the active asset. ### I chose real-time AR but it switched to AI Swap — why? [Section titled “I chose real-time AR but it switched to AI Swap — why?”](#i-chose-real-time-ar-but-it-switched-to-ai-swap--why) Real-time AR is only offered for eyewear and watch categories. Setting any other category moves the product to AI Swap automatically, since AR isn’t an option there. ### Why can’t I enable real-time AR for my product? [Section titled “Why can’t I enable real-time AR for my product?”](#why-cant-i-enable-real-time-ar-for-my-product) Same reason — the product’s category isn’t eyewear or watch. If the category is wrong, correct it on the product page. ### How long does 3D generation take? [Section titled “How long does 3D generation take?”](#how-long-does-3d-generation-take) A few minutes. The panel polls in the background and updates the asset status when it’s ready, so you can navigate away. ### How many photos or angles do I need for a good model? [Section titled “How many photos or angles do I need for a good model?”](#how-many-photos-or-angles-do-i-need-for-a-good-model) Up to four images are used. Front, side, and a 3/4 angle give the most accurate result; for eyewear, clean front and side shots matter most. ### Can I edit or replace a model after generating it? [Section titled “Can I edit or replace a model after generating it?”](#can-i-edit-or-replace-a-model-after-generating-it) Yes — generate again or upload a replacement at any time. Only one asset is **Active** at a time, and you choose which from the asset list, so a new model doesn’t go live until you switch to it. ## Plans and usage [Section titled “Plans and usage”](#plans-and-usage) ### What counts as a try-on session? [Section titled “What counts as a try-on session?”](#what-counts-as-a-try-on-session) Two different numbers get called “sessions”. Your **plan** meters try-on opens by *unique shopper per month* and AI Swaps per generation started. The dashboard’s **Try-on Sessions** card counts something else — AR model loads plus swap starts — as an engagement figure. See [Billing](/panel/billing/). ### What happens when I reach my monthly limit? [Section titled “What happens when I reach my monthly limit?”](#what-happens-when-i-reach-my-monthly-limit) Try-on keeps working — limits are soft, and shoppers aren’t turned away mid-month. On Shopify-billed paid plans, usage past the limit is charged per unit through Shopify’s Billing API, up to a capped amount per cycle. See [Billing](/panel/billing/) for the detail. ### Do my own test try-ons count toward my usage? [Section titled “Do my own test try-ons count toward my usage?”](#do-my-own-test-try-ons-count-toward-my-usage) No. Previews aren’t metered, so you can open them as often as you need while getting a product ready. Only real shopper sessions on your storefront count. ### How do I change my plan? [Section titled “How do I change my plan?”](#how-do-i-change-my-plan) From the **Plans & Pricing** section of the **Billing** page. Upgrades take effect immediately and are prorated; downgrades are scheduled for your next renewal, so you keep the plan you’ve paid for until the period ends. A scheduled downgrade can be cancelled from the same page with **Keep this plan**. To move to the free plan, use **Cancel subscription** rather than a downgrade. Only admins and members with the Billing role can do any of this — and see [Billing](/panel/billing/) for the full walkthrough. ### If one shopper tries several products, is that one session or many? [Section titled “If one shopper tries several products, is that one session or many?”](#if-one-shopper-tries-several-products-is-that-one-session-or-many) For **try-on opens**, one — the meter counts unique shoppers per month, so the same shopper across multiple visits still counts once. For **AI Swap**, each generation counts separately. ### What’s the difference between the plans? [Section titled “What’s the difference between the plans?”](#whats-the-difference-between-the-plans) Plans differ across four limits — try-on opens, AI Swaps, 3D generations, and how many products can have try-on enabled at once — plus feature access like advanced analytics. Current tiers are on the [pricing page](https://tryonvirtual.com/pricing). ### Do short or abandoned try-ons still count as a session? [Section titled “Do short or abandoned try-ons still count as a session?”](#do-short-or-abandoned-try-ons-still-count-as-a-session) For AI Swap, yes — a swap counts as soon as it starts, including if generation then fails, so a retry loop can’t run unmetered. For try-on opens it makes no difference, since that shopper is already counted for the month. ## Performance, troubleshooting and privacy [Section titled “Performance, troubleshooting and privacy”](#performance-troubleshooting-and-privacy) ### How do I know if try-on is actually helping me sell? [Section titled “How do I know if try-on is actually helping me sell?”](#how-do-i-know-if-try-on-is-actually-helping-me-sell) Look at **Try-on to Cart Rate** and **Widget Add-to-Cart Clicks** on the dashboard, then the funnel to see where shoppers drop off. See [Measuring results](/panel/measuring-results/). ### Where can I see how try-on is performing? [Section titled “Where can I see how try-on is performing?”](#where-can-i-see-how-try-on-is-performing) The **Dashboard**, over a 7, 30, or 90 day window — sessions, unique visitors, cart rate, saved looks, and a per-mode funnel. ### Does try-on work on mobile? [Section titled “Does try-on work on mobile?”](#does-try-on-work-on-mobile) Yes, in mobile browsers as well as desktop. Real-time AR uses the phone camera, so shoppers get a consent prompt and then the browser’s camera permission request. ### Which products get tried on the most? [Section titled “Which products get tried on the most?”](#which-products-get-tried-on-the-most) The dashboard ranks products by try-on activity. Detailed per-product breakdowns need a plan with advanced analytics. ### Try-on won’t load or looks broken — what should I check? [Section titled “Try-on won’t load or looks broken — what should I check?”](#try-on-wont-load-or-looks-broken--what-should-i-check) Confirm the product is enabled and its asset is active, that the bootstrap script on the page is the one scoped to that product, and that only one bootstrap script is loaded per page — a second one overwrites the first. [Developer troubleshooting](/developers/troubleshooting/) has the full list. ### Do you store my customers’ photos or camera data? [Section titled “Do you store my customers’ photos or camera data?”](#do-you-store-my-customers-photos-or-camera-data) It depends on the mode. **Real-time AR** processes the camera feed on the shopper’s device and doesn’t upload frames. **AI Swap** does upload the shopper’s photo, because generating the result requires it. See [Privacy and shopper data](/panel/privacy-and-data/). ### Is try-on privacy/GDPR compliant, and what data does it collect? [Section titled “Is try-on privacy/GDPR compliant, and what data does it collect?”](#is-try-on-privacygdpr-compliant-and-what-data-does-it-collect) Try-on collects an anonymous session ID, a per-device visitor ID, the product being tried, and diagnostic details like app version — no customer name, email, or order data. Both modes ask the shopper for consent first, and your own privacy policy and DPA are the authoritative documents for your compliance record. ## Still stuck? [Section titled “Still stuck?”](#still-stuck) The support chat in the panel reaches the team directly. Integrating through the API instead? [Developer troubleshooting](/developers/troubleshooting/) covers error codes and limits. # Getting started > Create your panel account, sign in, and turn on virtual try-on for your first product in about five minutes. The [merchant panel](https://panel.tryonvirtual.com) is where you manage products, 3D models, and try-on settings if you’re on WooCommerce, BigCommerce, Wix, or a custom storefront. On Shopify, try-on is managed from your Shopify admin instead, not this panel. Note This guide covers the panel UI. Prefer to script it? The [developer quickstart](/developers/quickstart/) walks through the same flow with the REST API. ## 1. Create your account [Section titled “1. Create your account”](#1-create-your-account) Go to the [signup page](https://panel.tryonvirtual.com/signup) and fill in your name, email, password, and business name. We generate a store slug from your business name automatically — you can edit it as long as it’s still available. This slug is how your storefront’s install snippet finds your shop, so pick something you’re happy keeping. ## 2. Sign in [Section titled “2. Sign in”](#2-sign-in) Two ways to get back in: * **Email and password** — the usual. * **Magic link** — enter your email on the sign-in page and we’ll email you a one-click sign-in link. It expires after 15 minutes, so request a fresh one if it’s gone stale. ## 3. Create your first product [Section titled “3. Create your first product”](#3-create-your-first-product) From **Products**, click **Add Product** and fill in: * **Title** — the handle (URL slug) is generated from this automatically. * **Category** — eyewear, watch, shoes, jewelry, clothes, bag, or luggage. This drives which try-on experience is available and how our AI understands the product, so pick the closest match. * **Images** — upload a few clean product photos. Saving takes you to the product page, where you choose a try-on mode — Real-time AR or AI Swap — and turn try-on on. See [Products](/panel/products/) for the details of each mode. ## 4. Install the widget [Section titled “4. Install the widget”](#4-install-the-widget) Once a product is enabled and ready, go to **Install Widget** in the sidebar. It lists every active product with a ready-to-copy script tag, plus the “Try On” button snippet to drop onto your product pages. Full walkthrough: [Widget & preview](/panel/widget-preview/). ## Next [Section titled “Next”](#next) [Products](/panel/products/) — categories, images, and the difference between AR and AI Swap in practice. # Measuring results > Read the panel dashboard — what each metric counts, how the AR and AI Swap funnels differ, and which cards need an upgraded plan. The panel **Dashboard** shows how shoppers are using try-on across your storefront. Pick a period (7, 30, or 90 days) at the top; every card follows that selection. ## Headline metrics [Section titled “Headline metrics”](#headline-metrics) | Metric | What it counts | | ----------------------------- | --------------------------------------------------------- | | **Try-on Sessions** | Real-time AR model loads plus AI Swap generations started | | **Unique Visitors** | Distinct shoppers who opened try-on | | **Try-on to Cart Rate** | Share of try-on sessions that led to an add-to-cart click | | **Widget Add-to-Cart Clicks** | Clicks on add-to-cart from inside the try-on widget | | **Looks Saved** | Try-on results a shopper saved | | **Save Rate** | Share of sessions where a look was saved | If you run both try-on modes, these cards also split each number into an **AR** and an **AI** breakdown underneath. Note **Try-on Sessions is an engagement metric, not your billing number.** It counts AR model loads plus swap starts, while your plan meters try-on opens by unique shopper per month. Expect this card to read higher than the usage shown on [Billing](/panel/billing/). Neither is wrong — they answer different questions. ## Engagement metrics [Section titled “Engagement metrics”](#engagement-metrics) Four further cards describe how deeply shoppers engage rather than how many arrive: * **Share Look Rate** — how often saved looks get shared. * **Looks Per Session** — average number of looks saved in one session. * **Explorers** — shoppers who tried on multiple products in a single session. * **Tempted** — shoppers who tried on the same product more than once. Explorers and Tempted are the two worth watching for merchandising: a high Explorers count suggests shoppers are comparing across your catalog, while Tempted flags individual products shoppers keep returning to without buying. ## The funnel [Section titled “The funnel”](#the-funnel) The funnel card shows where shoppers drop off, with stages that differ by try-on mode: * **Real-time AR** — Model Loaded → Look Saved → Added to Cart * **AI Swap** — Swap Started → Completed → Result Saved → Added to Cart A steep drop between **Swap Started** and **Completed** points at generation failures rather than shopper behavior. A healthy Completed count with few Added to Cart is a product or pricing signal, not a try-on problem. ## Product coverage and method breakdown [Section titled “Product coverage and method breakdown”](#product-coverage-and-method-breakdown) * **Product coverage** — how many of your products have try-on enabled, so you can judge how much of your catalog these numbers represent. * **Method breakdown** — the split between real-time AR and AI Swap across your catalog. ## Cards that need a higher plan [Section titled “Cards that need a higher plan”](#cards-that-need-a-higher-plan) Detailed per-product analytics and the engagement cards are gated behind the **advanced analytics** plan feature. On a basic plan those cards still render with labels visible but counts and rates blurred, and the funnel shows in teaser mode, so you can see what’s available before deciding. Tiers are on the [pricing page](https://tryonvirtual.com/pricing). ## Next [Section titled “Next”](#next) [Team & API keys](/panel/team-and-api-keys/) — invite teammates and set up API access. # Privacy and shopper data > What each try-on mode does with camera and photo data, what shoppers consent to, and what the analytics events record. The two try-on modes handle shopper data differently. If you’re answering a privacy question or filling in a data-processing record, the distinction matters. ## Real-time AR [Section titled “Real-time AR”](#real-time-ar) The camera feed is processed **on the shopper’s device**. Frames are rendered against the 3D model in the browser and are not uploaded to TryOn. Before the camera starts, the shopper is asked for consent, and the browser separately asks for camera permission. Both outcomes are recorded, so a declined prompt shows up in your dashboard rather than looking like a failure. ## AI Swap [Section titled “AI Swap”](#ai-swap) AI Swap works differently, and this is the part most often described incorrectly: the shopper’s photo **is uploaded**. It goes to the TryOn API, which forwards it to the processing engine that generates the result image. It does not stay on the device. The shopper consents before the photo is selected, and can supply an existing photo or take a new one. Note Retention on the processing engine isn’t documented on this site — see your privacy policy and DPA for how long generated results and source photos are kept, and for the controller/processor split. Don’t quote a retention period from these docs; there isn’t one here to quote. ## What the analytics events record [Section titled “What the analytics events record”](#what-the-analytics-events-record) Every try-on interaction writes an analytics event carrying: * An **anonymous per-visit session ID** and a **persistent per-device visitor ID**. Neither is derived from a customer account, an email address, or a name. * The **product and variant** being tried on. * **App version and user agent**, for diagnosing widget problems. * Event-specific metadata — for example, how long a shopper tabbed away mid-session. No customer name, email, address, or order data is attached to a try-on event. The visitor ID is what makes unique-visitor metering possible (see [Billing](/panel/billing/)) — it identifies a device across visits, not a person across your store. ## Consent and permission outcomes [Section titled “Consent and permission outcomes”](#consent-and-permission-outcomes) Consent is recorded separately for each mode, and a declined consent is a normal outcome rather than an error. Alongside it, the browser’s own camera decision is recorded — granted, denied, or blocked by a site policy before the shopper was ever asked. That last case is worth checking if AR sessions look unexpectedly low: a restrictive `Permissions-Policy` header on your storefront can block camera access outright. ## GDPR [Section titled “GDPR”](#gdpr) Try-on is built to operate under GDPR and collects only what’s needed to run the widget and report usage back to you. Because you’re the merchant of record on your own storefront, your privacy policy and DPA are the authoritative documents for your compliance record — including the processor chain for AI Swap, which involves the processing engine as well as TryOn. ## Next [Section titled “Next”](#next) [FAQ](/panel/faq/) — quick answers to the questions merchants ask most. # Products > Create products, pick a category, choose Real-time AR or AI Swap, and read the processing status shown in the panel. ## Creating a product [Section titled “Creating a product”](#creating-a-product) From **Products → Add Product**, fill in: * **Title** — the handle (URL slug) auto-fills from this; edit it if you want a different one. * **Category** — one of eyewear, watch, shoes, jewelry, clothes, bag, or luggage. * **Images** — a few clean photos of the product. Category isn’t just a label — it decides which try-on mode is available and shapes how our AI understands the product, so pick the closest match rather than leaving it generic. You can change it later from the product page. ## Real-time AR vs. AI Swap [Section titled “Real-time AR vs. AI Swap”](#real-time-ar-vs-ai-swap) Every product needs a try-on mode, chosen on the product detail page: * **Real-time AR** — the customer’s camera overlays a 3D model live. Only available for **eyewear and watches**; other categories don’t show this option. You need a 3D model on the product before this works — either upload one yourself (GLB, GLTF, USDZ, SPZ, or PLY, up to 20MB) or generate one from photos: pick up to 4 of the product’s images and we build the model automatically. Generation takes a few minutes; the panel polls and tells you when it’s ready. * **AI Swap** — a photo of your product is swapped onto the customer’s own photo. Works for every category, and needs no 3D model — just product photos, which get synced to the AI engine for processing. Read more about how swap works on the [AI swap try-on page](https://tryonvirtual.com/ai-swap-try-on). Non-AR categories (shoes, jewelry, clothes, bag, luggage) are set to AI Swap automatically once you set a category, since AR isn’t an option for them. ## Processing status [Section titled “Processing status”](#processing-status) **AR assets** show a status as they come in: `uploaded` → `analyzing` → `analyzed` (or `failed`). Once analyzed, an asset also gets a quality grade (excellent, good, acceptable, or needs work) — open its quality report from the asset row for details, or request optimization if the grade comes back low. Only one asset is “Active” at a time; that’s the one customers see, and you can switch which one is active from the same list. **AI Swap products** show an engine sync status instead: **Not synced → Processing → Ready** (or **Failed**, with a retry button). Sync kicks off automatically once you switch a product to Swap mode, using whatever images are on the product — make sure images are uploaded first. ## Enabling try-on [Section titled “Enabling try-on”](#enabling-try-on) The **Try-on Status** card on the product page has the on/off toggle. You need a mode selected before you can turn it on — the toggle is blocked until you’ve picked AR or Swap and, for AR, at least one asset exists. ## Next [Section titled “Next”](#next) [AR Fit Editor](/panel/ar-fit-editor/) — fine-tune how a 3D model sits on the customer for AR products. # Team & API keys > Invite teammates with the right role, and create or revoke API keys for your own systems from Settings. ## Team roles [Section titled “Team roles”](#team-roles) Invite teammates from the **Team** page. Every member has one role: | Role | Can do | | ------- | -------------------------------------------------------- | | Admin | Everything — products, team, billing, settings, API keys | | Editor | Manage products and 3D assets | | Billing | Manage billing and subscriptions | | Viewer | Read-only access to the dashboard and analytics | Only admins can invite people, change roles, remove members, or manage API keys. ## Inviting someone [Section titled “Inviting someone”](#inviting-someone) From **Team → Invite Member**, enter their email and pick a role. They get an emailed invitation; pending invitations show up in their own list until accepted, and you can resend or cancel one at any time from there. Once accepted, an admin can change anyone’s role or remove them from the team (you can’t change your own role from this page). ## API keys [Section titled “API keys”](#api-keys) If you manage products from your own systems instead of the panel — a sync job, an ERP, a custom storefront — you’ll need an API key. They live under **Settings → API Keys**: * Only admins can create or revoke keys. * A new key’s full value is shown **once**, right after creation — copy it immediately, because we only store a prefix after that for identifying it in the list. * You can have up to 10 active keys per shop. * Revoking a key breaks anything still using it, immediately and permanently — there’s no undo. For request format, headers, and rotation guidance, see [Authentication](/developers/authentication/) in the developer docs. ## Next [Section titled “Next”](#next) [Billing](/panel/billing/) — plans, usage, and how to upgrade. # Widget & preview > Preview try-on on a product before going live, then find the install snippets for every active product in one place. ## Previewing a product [Section titled “Previewing a product”](#previewing-a-product) Every product detail page has a **Preview** button. It opens the try-on widget in a new tab, running exactly as a customer would see it, using a short-lived scoped link generated just for that preview. This is the fastest way to check a product looks right before you put the button on your live storefront. Previewing doesn’t count against your plan’s try-on usage — open it as many times as you need while you’re getting a product ready. ## Install Widget page [Section titled “Install Widget page”](#install-widget-page) Once a product is enabled and ready, its install snippet shows up on the **Install Widget** page in the sidebar. For each active product you’ll find: * A product row with its title, category, and ID. * A ready-to-copy ` {%- endif -%} ``` ## Step 3 — Change the settings [Section titled “Step 3 — Change the settings”](#step-3--change-the-settings) The six `assign` lines at the top are the only ones you need to touch: | Setting | What it does | | ------------------------- | ------------------------------------------------------ | | `tryon_button_text` | The button label. Keep it short and action-shaped. | | `tryon_button_color` | Background colour, any CSS colour value. | | `tryon_button_text_color` | Label and icon colour. | | `tryon_button_radius` | Corner radius, e.g. `0`, `8px`, `999px` for a pill. | | `tryon_show_helper_text` | `true` or `false` — the line of copy under the button. | | `tryon_api_base_url` | Leave as-is. Only change it if support asks you to. | To restyle anything else, target `.tryon-vt-button` in your own theme CSS with `!important` — the snippet marks six properties important to survive theme resets, so an ordinary rule of yours won’t win against them. The button and helper text are English in the snippet. If your storefront is in another language, translate the `tryon_button_text` value and the two `tryon_helper_text` values directly in the code — this snippet doesn’t read your theme’s translation files. ## Step 4 — Test it [Section titled “Step 4 — Test it”](#step-4--test-it) 1. Open the storefront product page of a product **you enabled try-on for**. The button appears below add-to-cart. 2. Open any product you have **not** enabled. There should be no button and no empty gap. 3. Click the button — the try-on modal opens after a short load. 4. On a product with several variants, switch variant, then try on and add to cart from inside try-on. Check the cart holds the variant you picked. If it holds the wrong one, see troubleshooting below. 5. Check the [dashboard](/shopify/measuring-results/) the next day — **Views** should be counting. ## How it decides to render [Section titled “How it decides to render”](#how-it-decides-to-render) The snippet reads the `tryon.has_asset` product metafield, which the TryOn app keeps in sync when you enable or disable try-on on a product. Nothing else gates it. That’s why: * Enabling a product in the app makes the button appear with **no theme edit**. * Disabling one makes it disappear the same way. * Uninstalling the app leaves the snippet in place but renders nothing, because the metafield stops being maintained. It reads a second metafield, `tryon.model_type`, only to pick which line of helper text to show (AI Swap vs. real-time AR). ## Common questions [Section titled “Common questions”](#common-questions) ### Can we change the button colour and the button text? [Section titled “Can we change the button colour and the button text?”](#can-we-change-the-button-colour-and-the-button-text) Yes — both are single-line edits at the top of the snippet, and neither needs anything else touched: ```liquid {%- assign tryon_button_text = "Try it on" -%} {%- assign tryon_button_color = "#1a1a1a" -%} {%- assign tryon_button_text_color = "#ffffff" -%} ``` `tryon_button_color` and `tryon_button_text_color` take any CSS colour value — hex, `rgb()`, or a named colour. Save the file and hard-reload a product page to see the change. It applies to every try-on product at once; there’s no per-product override. ### Can the button match our theme’s button colour automatically? [Section titled “Can the button match our theme’s button colour automatically?”](#can-the-button-match-our-themes-button-colour-automatically) Sometimes. Most themes in the Dawn family expose their button colour as a CSS variable, so you can swap the colour lines in the `