Every virtual try-on API works the same way at the contract level: you send a photo of a person and a photo of a garment, and the API returns a composited image of that person wearing that garment. The decisions that actually shape your integration are the ones the product pages skip — which model version you are calling, what its input rules are, what it costs per image, and how the async lifecycle behaves when things go wrong.
This guide walks through the complete integration against a real endpoint — the Kling Kolors Virtual Try-On V1 model as routed by Modellix — then compares it with the alternatives that rank for “virtual try on api” today. Prices were pulled from live pages on August 25, 2026, and every figure below carries its date. This is not a “pick the winner” article: Modellix is an aggregator and has a commercial interest in the comparison, so the goal is a workflow you can verify yourself.
What a virtual try-on API needs from you
A try-on API is an image-to-image job with a fixed two-image contract. You provide:
- A person image — the model whose body the garment will be rendered on. For the Kolors VTO route, a clear frontal or side-view full-body photo works best.
- A garment image — a product photo, a flat-lay, or a white-background clothing image. The model transfers the garment onto the person while preserving the person’s pose and identity.
The output is a new image: the person wearing the garment. That is the entire product surface for the most common e-commerce use cases — product-page model shots, personalized recommendations, and “see it on you” previews.
The part that surprises most integrators is the lifecycle. Media generation takes seconds, so most providers in this category use an asynchronous submit–poll–retrieve pattern: your request returns a task ID immediately, and you poll a result endpoint until the job reaches a terminal state. Photta’s product page describes the same four steps — generate an API key, pick a mannequin, POST the try-on job, poll until the job completes. Google’s official Virtual Try-On documentation, by contrast, shows a synchronous predict-style call that returns the image directly. Once you understand the dominant contract, every virtual try-on API is a variation on it.
The two-image contract every virtual try-on API shares: person photo + garment photo → composited on-model result. Illustrative concept diagram.
Virtual try-on API pricing in August 2026
Pricing varies by route, model version, and billing unit, so the table below names all three. All figures were read from the live pages on August 25, 2026.
| Route | Model / product | Billing unit | Price (2026-08-25) |
|---|---|---|---|
| Modellix (aggregator) | Kling Kolors Virtual Try-On V1 | per image | $0.0900 |
| Modellix (aggregator) | Kolors Virtual Try-On V1.5 | per image | $0.0900 |
| fal.ai hub | Kling Kolors v1.5 | per generation | $0.07 |
| fal.ai hub | FLUX 2 LoRA Gallery | per processed megapixel | $0.021 |
| fal.ai hub | Decart Lucy 2.1 VTON Realtime | per second of streaming | $0.02 |
| FASHN | FASHN API suite | credit package | from $7.50 |
| Google (Vertex) | Gemini Enterprise VTO | not published per image | check official pricing |
Version discipline matters more than the numbers. The Modellix row is Kolors Virtual Try-On V1 — a legacy model kept for backward compatibility — while the fal hub row is Kolors v1.5, the newer pipeline that adds top+bottom combination try-on. Comparing “$0.09 vs $0.07” across those two rows is comparing two different model versions through two different middlemen, not a like-for-like price. On Modellix both V1 and V1.5 currently display the same $0.0900/image. None of this is a claim that Modellix is the cheapest route; on fal’s hub, Kling Kolors v1.5 is listed at $0.07 per generation, and Google’s enterprise VTO pricing is not published per image on its documentation page. The honest use of this table is as a starting set of numbers to re-check, not as a quote.
The Kolors Virtual Try On V1 model page is where the aggregator route’s current price and schema are displayed; fal’s prices above come from its virtual try-on hub.
Quick start: submit a virtual try-on job
The Modellix route for Kolors VTO V1 is a single POST to https://api.modellix.ai/api/v1/kling/kolors-virtual-try-on-v1 with an Authorization: Bearer header and a JSON body containing exactly two fields: human_image and cloth_image. Both accept a public image URL or a Base64 string — without the data: prefix. Create an API key in the Modellix console first; the request needs one real key.
1 | curl -X POST https://api.modellix.ai/api/v1/kling/kolors-virtual-try-on-v1 \ |
The submit response returns a task ID and the URL you will poll — it does not return an image:
1 | { |
Note what is not in the request body: there is no prompt, no aspect ratio, no resolution, and no negative prompt. Kolors VTO is a deterministic two-image transform, and its schema rejects those parameters — model_name is injected automatically by the system. If you come from text-to-image APIs, the instinct to add a prompt is the first thing to unlearn.
Poll the job and save the result
Generation takes 15–60 seconds on this route. Poll the get_result.url from the submit response with the same auth header until the status reaches a terminal state.
1 | import time |
Two persistence rules matter more than the polling loop itself:
- Results expire. Generated images on this route are valid for 30 days only — download or re-host the output before then, and do not hot-link the result URL as a permanent asset.
- Save promptly, don’t just log. The result object carries the generated image URL(s) in
result.resources[]; persist them to your own storage (S3 or equivalent) as part of the success path, not as a post-processing step.
If you do not want to poll at all, Modellix accepts an X-Webhook-URL header on the submit call. The webhook fires once the task reaches a terminal state (success, failed, or canceled) and carries the task result, delivered as a POST with an X-Modellix-Event header naming the event. The same submit–poll–webhook lifecycle is shared across every image and video route on the platform, which is what makes the aggregator’s image-to-video API guide a useful second read once you have this one working.
The async lifecycle behind every virtual try-on API: submit returns a task ID, poll until success or failure, then persist the result. Illustrative concept diagram.
Parameter rules, limits, and error handling
The Kolors VTO schema is small on purpose. Here is the complete contract as documented on the model page and API schema:
| Aspect | Rule |
|---|---|
| Request fields | human_image, cloth_image — both required, string (URL or Base64 without data: prefix) |
| Supported formats | .jpg, .jpeg, .png |
| Max image size | 10 MB per image |
| Min dimensions | 300 × 300 px |
| Input guidance | frontal or side-view full-body photo; product photo or white-background garment image |
| V1 capability | single garment: one top, one bottom, or a dress |
| V1.5 capability | single garments or a top+bottom combination merged into one white-background image |
| Unsupported parameters | prompt, negative_prompt, n, aspect_ratio, resolution, image_fidelity, image_reference — model_name is injected automatically |
| Typical latency | 15–60 seconds per task |
| Result validity | 30 days |
| Rate limit | 100 requests per minute at the entry tier (HTTP 429; X-RateLimit-Limit / X-RateLimit-Remaining / X-RateLimit-Reset headers); higher top-up tiers unlock higher RPM per the Modellix entitlements table |
Error responses follow a {code, message} shape where message is formatted as Category: detail. The three you will actually hit:
- 400 Invalid parameters — a missing or malformed field, an oversized image (>10 MB), or a dimension below 300×300. The message names the offending parameter.
- 401 Authentication failed — invalid or missing API key. Check that the key is active in the console and that the
Authorization: Bearerheader is intact. - 429 Rate limit exceeded: 100 requests per minute — you are above the per-minute quota. The
X-RateLimit-Resetheader tells you when the window clears; back off with an exponential retry rather than hammering.
For a batch pipeline, the right pattern is a small queue with a fixed concurrency (e.g., 5–10 in-flight tasks), each task polled independently, and failed tasks retried with exponential backoff. Since this is a legacy model maintained for backward compatibility, treat V1 as the stable fallback and evaluate Kolors Virtual Try-On V1.5 for new builds — the model page itself recommends V1.5 for new creations because it adds the top+bottom combination and higher output quality at the same displayed price.
Virtual Try-On API Reference
See the full submit and poll contract for Kolors Virtual Try-On and other image models on Modellix.
View DocsWhich virtual try-on API should you integrate?
The “virtual try on api” SERP is mostly vendor product pages, so the comparison framework is yours to build. These are the axes that actually separate the options:
Static vs. real-time. Static two-image try-on (Kolors VTO, FASHN, most of the fal hub catalog) is what you want for catalog photography and “see it on you” product pages. Real-time try-on over WebRTC — Decart Lucy 2.1 VTON Realtime at $0.02/second of streaming — is a different product for live camera experiences like virtual fitting mirrors. Do not evaluate them on the same price table; they are not the same workload.
Single garment vs. combination. V1 handles one garment (top, bottom, or dress). V1.5 adds top+bottom combos from a merged garment image. If your catalog sells outfits rather than singles, combination support should be a hard requirement.
Input tolerance. FASHN’s API exposes explicit controls (garment_photo_type for on-model vs. flat-lay inputs, a mode parameter trading speed against quality, and num_samples for batching variations). If your catalog photos are inconsistent — some on-model, some flat-lay — this kind of control matters more than a few cents per image.
Self-hosted vs. API. Open-weight families like IDM-VTON can be self-hosted on your own GPUs. That removes per-image fees but adds queueing, cold starts, and maintenance; for most teams an API is cheaper until volume is very high. There is no one right answer — there is a volume threshold.
Aggregator vs. direct. An aggregator like Modellix proxies many providers behind one key, one bill, and one submit–poll contract. The honest trade-offs: provider-specific parameters sometimes get flattened, brand-new models usually land on the vendor’s own API first, and the per-image price includes the platform’s margin. In exchange you get one integration that covers a dozen providers, Kling among them, per-task cost logs, and no per-vendor accounts. The virtual try-on collection on Modellix lists the try-on models available through that single contract; if try-on is your entire workload and you have one high-volume provider, price the direct route too — the table above shows exactly how.
Output quality also depends on your input population. Results vary with pose, body type, and garment fit — a model that looks great on a front-facing studio shot may degrade on side-view or loose-fit garments. Budget a visual QA pass across your actual catalog before committing to any route.
What try-on costs at catalog scale
Per-image pricing is easy to reason about, so here is the arithmetic for a mid-size catalog. All figures use the August 25, 2026 prices above.
| Scale | Kolors VTO V1 via Modellix ($0.0900/img) | Kling Kolors v1.5 via fal hub ($0.07/gen) |
|---|---|---|
| 1,000 images | $90 | $70 |
| 10,000 images | $900 | $700 |
| 100,000 images | $9,000 | $7,000 |
Read those columns with the version caveat from the pricing section: V1 and v1.5 are different pipelines, and the fal hub prices are the hub’s displayed rates on the access date — re-verify both before you build a budget. Two cost factors are invisible in per-image math: retry rate (a 5% failure rate adds 5% to unit cost) and expiry churn (regenerating an image you failed to save within 30 days is a second paid call). A reliable queue with persistence built into the success path is a cost control, not just an engineering nicety.
For reference on how aggregator pricing compares across the wider model catalog, the cheapest AI API roundup tracks image and video routes with the same dated-table discipline, and the Modellix pricing page shows the current rate card.
Start Generating Try-Ons
Log in to run Kolors Virtual Try-On and 200+ other image and video models on one Modellix key.
LoginFrequently Asked Questions
What is a virtual try-on API?
A virtual try-on API is an image-to-image service that takes a photo of a person and a photo of a garment and returns a composited image of that person wearing the garment. It is used by e-commerce teams to generate on-model product photos and personalized previews without a physical photo shoot.
How much does a virtual try-on API cost?
As of August 25, 2026, Modellix displays Kolors Virtual Try-On V1 and V1.5 at $0.0900 per image, fal’s hub lists Kling Kolors v1.5 at $0.07 per generation and FLUX 2 LoRA Gallery at $0.021 per processed megapixel, and FASHN’s credit packages start at $7.50. Google’s enterprise VTO pricing is not published per image on its documentation page. Prices change; re-check the live pages.
Is there a free virtual try-on API?
No major provider in the current SERP publishes a free tier with a per-image price of zero. The lowest entry points are small credit packages (FASHN from $7.50) or low per-generation routes such as fal’s Kolors v1.5 listing. If “free” matters, the realistic option is self-hosting an open-weight model like IDM-VTON on your own GPUs.
How long does a virtual try-on generation take?
On the Modellix Kolors VTO route, typical processing time is 15–60 seconds per task. The API is asynchronous: your submit returns a task ID, and you poll until the status reaches success, failed, or canceled.
What image formats and sizes do virtual try-on APIs accept?
For Kolors VTO, both human_image and cloth_image accept .jpg, .jpeg, or .png, with a maximum size of 10 MB and minimum dimensions of 300 × 300 pixels. A clear frontal or side-view full-body person photo and a product photo or white-background garment image give the best results.
Can I use a virtual try-on API on my own product photos?
Yes — that is the main production use. Flat-lay or white-background product photos are valid garment inputs for Kolors VTO, and FASHN’s API exposes an explicit garment_photo_type control for on-model versus flat-lay inputs. Run a visual QA pass across your actual catalog, since results vary with pose, body type, and fit.
Is Modellix cheaper than calling Kling Kolors directly?
Not as a blanket statement. On the matching display data, Modellix shows $0.0900/image for Kolors VTO V1 and V1.5, while fal’s hub lists Kling Kolors v1.5 at $0.07/generation — different model versions through different routes. Compare only the same model version and billing unit, then weigh the aggregator’s single-key, single-bill workflow and per-task cost logs against the direct route’s lower unit price.
Do virtual try-on APIs support real-time video?
Some do. Decart Lucy 2.1 VTON Realtime (via fal) streams try-on over WebRTC at $0.02 per second and is designed for live camera experiences. Static two-image try-on APIs like Kolors VTO and FASHN are a separate category for catalog and product-page images; do not compare them on the same price table.
Pricing and availability sources accessed August 25, 2026: the Modellix Kolors VTO V1 model page, fal’s virtual try-on hub, FASHN’s API page, Photta’s try-on API page, and Google’s Virtual Try-On documentation. Provider pricing and availability change frequently; validate against each live page before committing budget. Modellix is an AI model API aggregator and has a commercial interest in the routes it sells.
Cover image is illustrative Modellix artwork, not a provider screenshot or pricing evidence.