Google product variants need an image each: make one per colour

Google's product variant documentation says to group variants with a ProductGroup and, for each variant, give a unique ID, its own image URL, a distinct URL that preselects it, and its own offer. The image is the part a catalog often lacks. Sume's POST /v1/images can make a per-colour image from a single reference photo, which you then check against the real product.

The structured data rules are from Google's Product variant structured data page, read 2026-10-02.

What does Google require for variants?

The page names three properties for grouping: variesBy, hasVariant and productGroupID. Beyond grouping, it lists what each variant needs.

• ProductGroup carries shared properties such as brand and reviews.
• variesBy lists the aspects that differ, such as colour, size, material or pattern, as full schema.org URLs.
• productGroupID is the parent SKU, given on the group or via inProductGroupWithID on variants.
• Each variant has a unique ID, for example through sku or gtin.
• Each variant's Product should have its own image URL, and its own Offer with price and availability.
• Each variant must be preselectable with a distinct URL using query parameters.

Where does an AI image fit in?

Only in the per-variant image slot. A blue mug and a red mug that share one image breaks the point of the markup, because the shopper who lands on the red URL sees the blue mug. Where you already have a real photo of each colour, use it. Where you have a single photo and a manufactured colour range, an image edit can produce the missing ones.

That has a limit you must respect. An edit can shift a hue slightly; it cannot know your dye lot. Compare each output with a sample before it goes live, and drop any that do not match.

How do I generate one image per colour?

`POST /v1/images` takes a model, a prompt and input_references as public HTTPS image URLs. The docs advise aspect_ratio: "auto" on edits so the output matches the source. A single call can block for up to 30 seconds and returns 200 with data[].url; if it runs longer, you get 202 and a job to poll.

The loop below makes one call per colour and handles the 202 case by printing the status URL rather than guessing.

import os, requests

H = {"Authorization": f"Bearer {os.environ['SUME_API_KEY']}"}
SRC = "https://example.com/mug-088-white.jpg"
for colour in ["navy blue", "forest green", "mustard yellow"]:
    r = requests.post("https://api.sume.com/v1/images", headers=H, timeout=60, json={
        "model": "openai/gpt-image-2.5",
        "prompt": f"Same mug, same angle and lighting, recolored {colour}. Nothing else changes.",
        "input_references": [{"type": "image_url", "image_url": {"url": SRC}}],
        "aspect_ratio": "auto"})
    r.raise_for_status()
    body = r.json()
    if r.status_code == 200:
        print(colour, body["data"][0]["url"])
    else:
        print(colour, "queued:", body["data"]["status_url"])

How do I keep the markup and the images in step?

Name the output by SKU, not by colour word, and store the URL beside the sku in your catalog table. Your template then writes the JSON-LD from that row, so a variant cannot exist without its image. If a colour fails review, leave that variant's image empty in the data and fix it, rather than reusing a neighbour's picture.

For the platform-specific version of the same job, see the post on one AI image per Shopify variant.

What does Sume not do here?

It does not write your structured data, check it against Google's tools, or influence how Google ranks or displays the variants. It makes images. The page above says what markup is expected; whether it is eligible for a rich result is for Google's own testing to say.

One last point on cost: image generation billing is all-or-nothing per call, so a call that fails costs nothing, and a call that succeeds bills for every image in it. Three colours is three calls above, and the price for each is in the usage block of the response, so read that rather than assuming a number. When you scale to a catalog with a long colour range, log that cost beside the SKU so you know what each variant image cost you. Review is the other cost: a person has to look at every generated colour next to a real sample, and that time is usually larger than the generation bill.