Google Virtual Try On API: Integration Guide, Pricing & Code

Google has a virtual try-on API, and the first search result for “google virtual try on api” is not it. It is the free consumer try-on inside Google Shopping — the thing shoppers use, not the thing developers call. The developer-facing product lives one level deeper: a dedicated model, virtual-try-on-001, served through Google’s Gemini Enterprise Agent Platform (the Vertex AI product line), priced at $0.06 per generated image as of August 19, 2026.

That distinction matters because most of what ranks for this query muddles the two. This guide gives you the developer answer: what the API actually is today, verified same-day pricing, working Python and REST code, the integration constraints the official docs don’t call out, and an honest comparison with the alternatives (including Kling Kolors VTO and FASHN) for when a Google Cloud setup is more friction than your use case deserves. Modellix is an API aggregator and has a commercial interest in the alternatives section; everything stated about Google’s API is drawn from Google’s own documentation and stands on its own.

Google has a virtual try-on API — but not where most people look

Four things are called “Google virtual try-on,” and only one is an API:

1. Google Shopping’s “Try on you” tool (google.com/shopping/tryon) — a consumer feature where shoppers preview clothes on generated models. Free for shoppers, no API surface.
2. Merchant Center apparel try-on — an opt-in shopping feed feature for retailers that want product imagery shown on real models. Free for shoppers; a feed integration, not a model API.
3. The old Gemini API tryon capability — this was the one that used to be a plain API call. The preview model that carried it (gemini-2.0-flash-preview-image-generation) was removed on November 14, 2025, per Google’s deprecations page. If your integration predates that, it is already broken and there is no direct replacement on the standard Gemini API.
4. The virtual-try-on-001 model on Gemini Enterprise Agent Platform — the actual API: send a person image plus a product image, get back the person wearing the product. This is the model this guide integrates.

The model’s lifecycle is stated plainly on its official model page: GA since January 20, 2026, retirement scheduled January 20, 2027. It is not a preview and not deprecated today — but the retirement date means this is a model you should treat as replaceable, exactly like the Gemini-API-era tryon that vanished without a direct successor. The same discipline applies across Google’s image model family; our Imagen 4 API guide documents a sibling model that went through the same kind of lifecycle. It is also a GA product with a real retailer story behind it: German fashion house Breuninger built a selfie-based “be your own model” experience on the VTO API through Google’s Trusted Tester Program and, in a six-week A/B test over Black Week and the holiday season, found try-on users converted at a higher rate with a stronger contribution margin than shoppers who did not use it. For e-commerce and fashion retailers evaluating the API, that is the closest thing to public proof-of-concept data.

What the Google Virtual Try-On API costs

Google bills Virtual Try-On per generated image, and the rate is public. Read from the official Generative AI pricing page on August 19, 2026:

Model	Input	Output	Price
virtual-try-on-001	1 person image + 1 clothing image	1 generated image	$0.06 / image

How the unit works in practice: one request consumes two input images and produces between 1 and 4 output images (sampleCount 1–4). The $0.06 figure is per output image, so a single request with sampleCount: 4 costs $0.24 — not $0.06. A modest catalog-rendering job of 10,000 images costs $600 at standard pay-as-you-go rates. There is no minimum commitment; you pay for what you generate, billed against your Google Cloud project.

Two caveats worth knowing before you budget:

• The free-credit math is GCP, not VTO. New Google Cloud customers get a $300 trial credit, which covers roughly 5,000 generated images at this rate — useful for an evaluation, not a free tier of the model itself. There is no VTO-specific free quota.
• Provisioned Throughput exists. The model page lists Provisioned Throughput as a supported consumption option for teams that need committed capacity; standard pay-as-you-go is the default and the numbers above assume it. Prices move — treat this table as a dated snapshot (August 19, 2026), not a quote.

How virtual-try-on-001 works: two images in, one worn image out

The model contract is deliberately narrow. You supply a person image and one product image; the model returns the person wearing that garment. No text prompt, no scene description, no style guide — the model page lists text input as not supported. Output images inherit the aspect ratio and resolution of the input person image, and generated content carries C2PA content credentials.

The technical constraints you will actually hit during integration:

Constraint	Value
Input images per request	Max 2 (1 person + 1 product)
File size per image (inline/base64)	Max 7 MB
Output images per request	1–4 (sampleCount / candidateCount)
Supported MIME types	image/png, image/jpeg
Output format	Same aspect ratio and resolution as the input person image
Text prompt support	Not supported
Content credentials (C2PA)	Supported

Concept diagram of the virtual-try-on-001 contract: person image + product image → worn image. Illustrative, generated August 19, 2026; no product screenshot because the model has no public UI.

Input quality follows the same logic Google documents for the Merchant Center apparel feature (support page): one garment fully visible per image, a clean pose, and high resolution — the better the product photo, the better the draping and fabric detail in the output. Model the person image the same way: front-facing, well lit, full garment area unobstructed.

Integrate the Google Virtual Try-On API: Python and REST

Everything below is verified against the official capability documentation (fetched August 19, 2026). The setup has three prerequisites, and all three are Google Cloud, not model-specific:

1. A Google Cloud project with billing enabled, and the Agent Platform API enabled for it.
2. Authentication via Application Default Credentials — for local development, gcloud auth application-default login. This API does not take a plain API key the way the old Gemini API did; ADC (or a service account) is the supported path.
3. Region awareness — the model is available in a defined region list (US, Canada, Europe, Asia-Pacific, and Middle East regions; check the locations page for the current list). Your request URL and your project’s location must line up.

Python (Google Gen AI SDK)

# pip install --upgrade google-genai
# export GOOGLE_CLOUD_PROJECT=your-project-id
# export GOOGLE_CLOUD_LOCATION=global
# export GOOGLE_GENAI_USE_ENTERPRISE=True
# gcloud auth application-default login

from google import genai
from google.genai.types import Image, ProductImage, RecontextImageSource

client = genai.Client()

result = client.models.recontext_image(
    model="virtual-try-on-001",
    source=RecontextImageSource(
        person_image=Image.from_file(location="person.jpg"),
        product_images=[
            ProductImage(product_image=Image.from_file(location="sweater.jpg")),
        ],
    ),
)

result.generated_images[0].image.save("worn.png")
print(f"saved {len(result.generated_images[0].image.image_bytes)} bytes")

Note the method name: recontext_image is the SDK surface the docs use for this model. Image.from_file(location=...) reads local files; product_images takes a list because the API supports a product image per output when you generate several variants.

REST (curl)

The REST surface is a standard Vertex-style predict call on the publishers model path:

gcloud auth print-access-token   # capture the token

{
  "instances": [
    {
      "personImage": { "image": { "bytesBase64Encoded": "BASE64_PERSON_IMAGE" } },
      "productImages": [
        { "image": { "bytesBase64Encoded": "BASE64_PRODUCT_IMAGE" } }
      ]
    }
  ],
  "parameters": {
    "sampleCount": 1,
    "storageUri": "gs://YOUR_BUCKET/vto-output/"
  }
}

curl -X POST \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  -H "Content-Type: application/json; charset=utf-8" \
  -d @request.json \
  "https://REGION-aiplatform.googleapis.com/v1/projects/PROJECT_ID/locations/REGION/publishers/google/models/virtual-try-on-001:predict"

Replace REGION, PROJECT_ID, and the two base64 image values. The response returns the generated images as base64-encoded PNG objects inside predictions, and the storageUri you set is where output is written for retrieval.

Concept diagram of the REST flow: personImage + productImages → predict → storageUri output. Illustrative, generated August 19, 2026.

Integration constraints and common errors

The failures that cost time are rarely syntax errors:

• Forgetting storageUri on REST. The predict call needs a Cloud Storage path for output. Teams that omit it get errors or empty results because the REST flow is storage-backed. The Python SDK hides this for you; raw REST does not.
• Auth mismatch. This is Vertex, not the old Gemini API: an API key will not work. ADC (gcloud auth application-default login) for local dev, a service account for production. The most common first-hour error is trying to reuse a Gemini API key.
• Input-image rules. Two images max, 7 MB per image, PNG or JPEG only. Product images with multiple garments, heavy background clutter, or cropped garments degrade output — follow the Merchant Center guidance (one garment fully visible, ≥512 px, clean background) and you will see better fabric fidelity.
• Output inherits input. There is no resolution parameter. If you need large output images, the person input must already be large. A 512×512 person photo yields 512×512 output, no upscaling.
• No text prompt. The model ignores textual instructions. If you need guided composition, this model is not the tool.
• Region and quota. The endpoint is REGION-aiplatform.googleapis.com, and region must be one where the model is deployed. Quotas are per-project; batch inference is not supported, so high-volume rendering means managing concurrent requests within your quota.

Google VTO vs the alternatives: Kling Kolors, FASHN, and the aggregator route

virtual-try-on-001 is not the only try-on API on the market, and for many teams it is not the easiest one to start. The honest comparison on the dimensions a developer actually chooses on:

Route	Model / surface	Price (Aug 19, 2026)	Setup friction	Best fit
Google VTO API	virtual-try-on-001 on Gemini Enterprise Agent Platform	$0.06 / image	Google Cloud project, billing, ADC, region	Teams already on GCP, enterprise fashion retailers
Kling Kolors VTO via Modellix	Kolors Virtual Try-On V1 / V1.5	$0.09 / image	One API key, no cloud project	Developers who want an API key and no GCP setup
FASHN	FASHN API	Credit packs; no per-image price published on the API page as of Aug 19, 2026	Account + credits	Fashion teams wanting a full suite (model creation, product photography) beyond try-on

Two structural notes. First, Google’s $0.06 is cheaper per image than Modellix’s $0.09 on the Kling route — the aggregator is not a price play here; it is a setup play. The trade is: Google requires a cloud project, billing, ADC, and a region decision before your first call, while Modellix hands you an API key and the same request style you use for every other model in the catalog (the Google provider page lists which Google models sit behind that key). That is an access-path trade-off, not a claim that aggregators are cheaper. Second, the broader “virtual try-on api” SERP is crowded with roundups of vendors (Pixelcut, API4AI, Glamar, LightX among them) — the comparison above is deliberately limited to the two routes with verifiable same-day numbers plus the one credit-based suite.

If your team is already on Google Cloud, the VTO API is the natural first call. If you are evaluating try-on from outside GCP — a startup, a middleware product, a team that wants one bill across many models — the API-key route removes an entire layer of setup, and you can A/B the same pair of test images against both models before committing. Google’s own case study shows the model quality is real; the question is which integration path your team can ship.

Which try-on route should you integrate?

If your main reason is…	Start with…
You’re already on Google Cloud with billing and ADC set up	virtual-try-on-001 directly
Lowest per-image cost at scale on GCP	virtual-try-on-001 (and check Provisioned Throughput for committed volume)
No GCP project, want a single key and no region dance	Kling Kolors VTO via Modellix
Fashion suite beyond try-on (virtual models, product photography)	FASHN
You need video try-on	Neither — video try-on is a different product category; see our image-to-video API guide

The one experiment worth running before any commitment: take the same person photo and the same product photo, generate with Google’s model and with Kling’s, and compare draping, fabric detail, and garment fidelity side by side. Quality differences between try-on models are visible within a handful of images, and the test costs a few dollars at either rate.

Frequently Asked Questions

Is the Google virtual try-on API free?

No. The model bills per generated image — $0.06 at standard pay-as-you-go as of August 19, 2026. New Google Cloud customers do get a $300 trial credit, which covers roughly 5,000 images during an evaluation, but that is a GCP signup credit, not a free tier of the model. The free thing people usually find is Google Shopping’s consumer try-on, which is free for shoppers and is not an API.

What is the difference between Google Shopping try-on and the virtual try-on API?

Google Shopping’s “Try on you” is a consumer feature: shoppers see clothes on generated models, and retailers participate through the Merchant Center apparel feed. It has no developer API surface. The virtual-try-on-001 API is the paid developer product on Gemini Enterprise Agent Platform: you call it, you pay per image, and you control the output.

Do I need a Google Cloud project to use it?

Yes. The API runs on Gemini Enterprise Agent Platform (Vertex), which requires a Google Cloud project, billing enabled, the Agent Platform API enabled, and authentication via Application Default Credentials rather than a plain API key. That setup is the single biggest difference from the old Gemini API tryon capability, which was removed in November 2025.

Can I call the Google virtual try-on API from Python?

Yes. The Google Gen AI SDK exposes it as client.models.recontext_image(model="virtual-try-on-001", ...); the “Integrate” section above has a complete, copy-pasteable example with the required environment variables.

Does the API support video?

No. virtual-try-on-001 is image-in/image-out; the model page lists video and audio as unsupported, and batch inference is not supported either. Video try-on is a separate product category with its own providers.

Does Modellix offer virtual try-on?

Yes. Modellix aggregates the Kling Kolors Virtual Try-On models (V1 and V1.5) behind its unified API — one key, one bill, no Google Cloud project — at $0.09 per image as of August 19, 2026. Modellix is an aggregator and this is the section where we have a commercial interest; the honest caveat is that Google’s own per-image price is lower, and the point of the aggregator route is access-path simplicity, not a price ranking.

---

Provider details and pricing reflect public information as of August 19, 2026, and change frequently. Validate against each provider’s live pricing before committing. Access image and video models, including the leading Chinese models, through a single API key at modellix.ai.