ChatGPT Try On saves a reference photo: what your own flow should keep

If you are building a try-on feature of your own after ChatGPT's launch, the short answer is: store the shopper's reference photo only where you can show it and delete it, send Sume nothing but public HTTPS URLs for the request, and keep the Sume result URL as the record of what was generated. OpenAI's own help text describes its choice; yours has to be written down as a separate decision.

On October 1, 2026, OpenAI added a Try on button to clothing and accessory listings in ChatGPT shopping. According to OpenAI's pages, the shopper takes or uploads a selfie or full-body photo, or uploads a product screenshot, and ChatGPT shows the item on them (read 2026-10-03). The reference photo is saved for future try-ons and can be changed or deleted in Settings, under Personalization and Reference photos (read 2026-10-03). This post only repeats what those pages say. It makes no claim about how OpenAI processes the photo beyond that.

What OpenAI's pages say, and what they do not

The useful part for a builder is the shape of the feature: one saved photo per person, reused across items, with a visible place to change or remove it. Those are product decisions, not API features, and they transfer to any store.

What the pages do not give you is anything about your own legal position. Consent wording, retention periods and regional rules depend on where your shoppers live and what you tell them. Sume docs do not describe a consent flow either, so treat that as your own work and take legal advice on it rather than copying another vendor's screen.

Where Sume sits in your own flow

Sume's Image API takes reference images as public HTTPS URLs. Localhost, private-network and non-HTTPS URLs are rejected before the job starts, so a photo that lives behind a login or a signed link has to be exposed some other way, for a short and deliberate window, before you call. Think about that window before you think about prompts.

The Image API returns a Sume-hosted URL on media.sume.com for each result and a usage block with the billable cost. Store that URL next to your own shopper and item ids. The asset library doc covers how generated files are kept for later reuse in a workspace.

A workable minimum is three records on your side: the shopper id, a pointer to the reference photo you hold, and the Sume result URL per try-on. Deleting the reference photo from your store is then one operation, and you can see which generated images came from it. Whether a generated image must also be deleted is a policy you set; Sume does not decide it for you.

import requests, os

H = {"Authorization": f"Bearer {os.environ['SUME_API_KEY']}"}
body = {
    "model": "openai/gpt-image-2.5",
    "prompt": "Show the person in image 1 wearing the jacket in image 2. "
              "Keep face, pose and background unchanged.",
    "aspect_ratio": "auto",
    "input_references": [
        {"type": "image_url", "image_url": {"url": "https://cdn.example.com/ref/shopper.jpg"}},
        {"type": "image_url", "image_url": {"url": "https://cdn.example.com/sku/jacket.jpg"}},
    ],
}
r = requests.post("https://api.sume.com/v1/images", json=body, headers=H, timeout=60)
r.raise_for_status()
print(r.status_code, r.json().get("data") or r.json())

Decisions to make before launch

Pick these before you write a line of UI, because each one changes what you build.

• Who can see the reference photo: only the shopper, or your support staff too.
• How long the photo lives after the last try-on, and what a deletion request removes.
• Whether the photo is sent to Sume at all: the call needs a URL, so decide how long that URL stays reachable.
• What you say next to the result: a rendered image is a preview, and the QC checklist for fake-looking try-ons covers what to check.
• Whether the shopper can start from a product screenshot, as ChatGPT allows, which the screenshot try-on post walks through.