The vocabulary of virtual try-on, and the terms this platform uses for its own moving parts.
Two kinds of term are mixed together here on purpose: the ones the whole category uses, and the ones specific to how this platform is built. The second kind is where integrations usually go wrong, because the words look generic and are not.
A visible marker on a generated image declaring that it is synthetic. The EU AI Act pushes towards disclosure of this kind. Not implemented here — the account setting and the database column exist, the compositing step does not, and the docs said otherwise until September 2026.
A Shopify mechanism where a request to the merchant's own domain is forwarded to the app's server with Shopify's signature attached. It is how the try-on widget authenticates on a Shopify storefront without any key appearing in the page HTML.
Try-on rendered live through the device camera using 3D models of the product. Strong for rigid accessories — glasses, watches, jewellery — because a rigid object can be modelled exactly. Weak for garments, which drape. A different technique from generative try-on, not a better or worse version of it.
A generated result gradually resembling a more typical body than the one in the input photograph. The main accuracy risk in extended sizing, and the reason the plus-size page declines to make a claim. There is no automated check for it here yet.
An open standard for provenance metadata embedded in a media file, recording how it was produced. Not written by this platform today.
The billing unit. One successful try-on costs one credit regardless of how many garments compose the outfit. A failed or refused generation costs nothing. Credits are bought in packs, do not expire, and have no cash value.
Data Subject Access Request — a person exercising their right to see, correct or delete the data held about them. Here it is a manual process: there is no self-service deletion and no erasure endpoint yet. See the privacy policy.
A check that refuses when it cannot run, rather than allowing. Photo screening and rate limiting both fail closed here. The alternative — defaulting to "allowed" on error — is useless precisely at the moment the check matters, because outages and attacks correlate.
A cached text description of a product, generated once by a model and reused on every subsequent try-on of that product. It is why the second try-on of a garment costs less to serve than the first.
Try-on produced by an image model generating a new picture of the person wearing the garment, as opposed to compositing or 3D rendering. Handles drape and soft goods well; approximate on fine detail, text and logos.
An operator who licenses this codebase, rebrands it and sells try-on to their own customers. Most of the platform's configuration exists because the host — not the vendor — owns the currency, the payment gateway, the credit prices and the legal identity.
A generated result no longer looking like the person in the input photograph. Distinct from body drift, which is about proportions rather than face. No automated check for it exists here.
A single-use code, valid 24 hours, in the form GF-XXXX-XXXX-XXXX, that a merchant pastes into a plugin to connect a store. Used instead of asking them to copy an API key around. Only a hash of it is stored.
A model that takes images and text together and can generate images. Both providers wired here are of this family, which is why the roadmap's second provider family — a specialist try-on endpoint — is still an open item.
The list of web origins a publishable key may be used from. A publishable key with an empty allowlist is refused, at creation and at every resolution: an empty list must never be read as "allow anywhere".
Combining several garments into one try-on. Up to six compose in a single provider call, layered in the order sent, charged as one credit.
The median and 95th-percentile latency. p50 is the typical wait; p95 is what a shopper hits when things are slow. The gap between them matters more than either alone, because an inconsistent wait is worse than a uniformly slower one.
A key intended to be visible in a storefront's HTML. It is public by definition, and what bounds it is the origin allowlist and the rate limits — never secrecy. Contrast with a secret key, which must stay server-side.
The rule that a model joins the routable pool only by clearing a benchmark, and that cost is optimised within that pool rather than against it. The alternative — treating quality as one weight among several — lets a cheaper, worse model win on price.
Four layers, checked cheapest first: per shopper, per staff user, per account, per platform. An account is a webshop, so its traffic is a whole customer base; limiting it as if it were one person was the original mistake.
How long a shopper's photograph is kept before automatic deletion — 1, 3 or 7 days, set per account. The expiry date is part of the storage path, so a sweep is a prefix scan rather than a join.
The automated check every shopper photograph passes before any generation model sees it: sexual, violent and self-harm content, plus whether the subject appears to be an adult. It fails closed, and it logs its verdict and signals but never the image.
A random identifier the widget stores in the shopper's browser to enforce fair-use limits. It is a rate-limit key and never an authorisation: possessing one grants nothing.
A time-limited link to a private stored object. Images here are never in a public bucket; reads are signed for ten minutes. Objects are stored with caching disabled, because a cached copy outlives the deletion that was supposed to remove it.