ChatGPT virtual try-on and shopping images: when Bubble catalogs need try-on, not just BIAIG bulk
Try-on in ChatGPT and Google runs on-platform. I keep SKUs, angles, and policy flags in Bubble and generate catalog variants via bulk APIs—not a home-grown try-on renderer.
Why this matters now
On October 1, 2026, OpenAI shipped global virtual try-on in ChatGPT shopping surfaces—web and mobile. I still see merchants running static SKU grids and ad image variants in Bubble. For me the decision is not whether to use AI images, but where generation lives and what the catalog must store either way. Worth reading next: Meta Muse Image on fal.
In this article BIAIG bulk is my editorial shorthand for catalog-scale still generation via programmatic paths (Merchant Product Studio, Vertex Imagen batch/recontext, etc.)—not a public product name from the sources I reviewed. Worth reading next: OpenArt Bulk Create (500 CSV.
Two different tracks
| Need | Where it happens | Bubble’s job |
|---|---|---|
| Static SKUs, extra angles, lifestyle/backgrounds for ads and merchant feeds | Bulk API / Product Studio / Vertex pipelines | PIM layer: variant IDs, image_url, additional_image_urls, category, size/color, availability, AI/metadata flags |
| Shopper «Try on» in ChatGPT or Google Shopping | Inside ChatGPT / Google (Images 2.5 + user photo + listing imagery from the feed) | Do not composite try-on in Bubble; supply feed-compliant stills and attributes |
OpenAI’s try-on flow: eligible clothing and accessories in the shopping carousel can show «Try on»; the shopper uploads a selfie or in-chat screenshot; the preview is generated with ChatGPT Images 2.5. Google Shopping try-on similarly combines merchant feed imagery with user photos on Google surfaces. Merchants do not receive user try-on assets per OpenAI/Google help documentation.
Decision tree for Bubble developers
1. Do you need interactive try-on in your own app?
- No—goal is ChatGPT / Google discovery → I would not build a Bubble-hosted virtual try-on pipeline. It duplicates the platform and adds privacy, consent, and biometric-adjacent handling that feed-based discovery does not require.
- Yes—try-on only on your Bubble site → separate product scope; this plan does not cover it. ChatGPT shopping try-on does not replace that.
2. Are static grids + ad variants enough?
- Yes → I prioritize canonical SKU records: stable IDs, primary + angle URLs,
google_product_category/product_type, size/color, availability, policy flags (AI-generated, IPTC). - I generate variants via bulk paths (e.g.
generateProductImageBackground, Vertex background replace, batch recontext)—not Google Pics in Workspace as the only pipeline. That is creative tooling for humans/campaigns, not catalog batch APIs.
3. Do you want a «Try on» badge in ChatGPT shopping?
- You need a product feed under the Agentic Commerce Protocol: required
image_url, optionaladditional_image_urls, apparel-oriented fields; onboarding is currently partner-gated (approved partners; Shopify/Etsy cited as integrated). I treat assuming a Bubble-only static grid surfaces in ChatGPT shopping without feed work as risky. - Bubble should still hold the same fields you export to the feed (or sync from upstream PIM).
4. Google Merchant in parallel?
- AI-generated listing images must retain IPTC
DigitalSourceType(e.g.TrainedAlgorithmicMedia); CDNs that strip IPTC risk disapprovals. - Minimum 500×500 for
image_link/additional_image_link: enforcement from 2026-01-31, warnings from 2026-04-14 (2026 spec update). - Try-on eligibility depends on category and image rules (512px+ ideal 1024px+, single-garment model/flat-lay); eligible apparel feeds are generally auto-enrolled—I watch for category mismatch.
What to store in Bubble (both paths)
A minimal set aligned with the ACP feed spec and merchant practice:
- Identity: stable variant ID, SKU, product link.
- Imagery: primary
image_url,additional_image_urlsarray (angles, on-model, flat-lay—whatever platforms use for try-on heuristics). - Merchandising: title, description, price, availability, size, color, category (
google_product_category/product_type). - Policy / provenance: flag for AI-generated catalog assets; CDN rules that preserve IPTC; internal note that try-on previews are not fit/size guarantees (OpenAI and Google document this explicitly).
- Integration: system of record (Bubble vs external PIM), feed update cadence per OpenAI Commerce get-started guidance.
Try-on reference photos live in the shopper’s account (ChatGPT: Settings → Personalization → Reference photos). I do not plan to store or reuse them without a separate lawful basis—platforms do not offer these assets to merchants.
Honest limits
- Try-on previews may not match product or appearance exactly; if I do not promise fit in the UI, they are not merchandising truth—less returns and compliance risk.
- Public eligibility rules for ChatGPT’s «Try on» button are less detailed than Google’s category lists; exclusions (accessories, swim, lingerie, etc.) may differ between platforms.
- Bulk generation implies cost, rate limits, and QA (fidelity, policy). I plan governance, not a one-click whole-catalog assumption.
- Regional nuance: try-on is described as a global rollout; merchant pages still stress U.S. shopping—discovery vs try-on by region may differ (open question in the research pass).
Bottom line
For a typical Bubble catalog with SKU grids, ads, and Google/Meta feeds: I generate stills via bulk APIs and store rich compliant records and IPTC-safe URLs. ChatGPT/Google try-on is a platform feature on top of your feed, not a reason to build per-shopper rendering in Bubble. Same topic: Meta Muse / Instagram (Oct.
Scout packet sources: OpenAI Help «Shopping with ChatGPT Search», ChatGPT Images 2.5, Agentic Commerce product feed spec, OpenAI Commerce get-started, Google Merchant try-on and AI-generated content / 2026 spec update, Merchant API Product Studio, Vertex Imagen editing/recontext, Google Pics in Workspace (contrast).