Product feeds for AI shopping

A product feed is a structured inventory of what you sell. Its value comes from accurate, current product data and a destination that agrees with it. A feed is not a substitute for merchant onboarding, platform eligibility, or a working purchase path.

Begin with the source of truth

Identify the system that owns each field: catalog for identity and variant attributes, pricing for amounts and promotions, inventory for availability, and commerce operations for shipping and returns. Decide which system wins when they disagree. Updating the export file without fixing its upstream source produces recurring errors.

Model a purchasable variant, not just a marketing family. Size, color, bundle contents, subscription terms, and region can change the actual item a shopper receives. Keep the identifier stable across ordinary updates. Do not reuse a discontinued item's identifier for an unrelated replacement.

A concrete file-upload example

OpenAI's current product file-upload specification requires nine fields and one row per purchasable item or variant. Its price field uses an amount and currency string. The following is a fictional example record illustrating those fields, not a complete upload file or a live merchant submission. Official specification.

{
  "item_id": "trail-bottle-750-blue",
  "title": "Example Trail Bottle — 750 ml — Blue",
  "description": "A reusable 750 ml bottle with a screw cap.",
  "url": "https://example.com/bottles/trail-750-blue",
  "brand": "Example Outdoors",
  "seller_name": "Example Outdoors Store",
  "image_url": "https://example.com/images/trail-750-blue.jpg",
  "availability": "in_stock",
  "price": "24.00 USD"
}

Check the receiving platform's current accepted file format, field rules, limits, and account instructions. Do not transplant these field names into another merchant protocol and assume compatibility. For optional values, absence is better than invented identifiers or fabricated stock information.

Reconcile the representations

Choose a sample containing an ordinary item, a variant family, an out-of-stock item, and a promotion. Compare the source system, exported record, platform acceptance report, visible landing page, structured markup, and checkout. The same identifier must lead to the intended variant and its real offer.

A successful upload means the platform accepted data according to its response. It does not necessarily mean the item is visible, selected for a query, or available to purchase through an assistant. Keep these states distinct in the integration log.

Treat freshness as a product requirement

A catalog updated nightly may be adequate for a stable description and inadequate for scarce inventory. Set a freshness target for each field based on how costly stale information would be. Use the platform's documented update mechanisms; after an update, inspect the returned status and a representative item rather than assuming transmission equals ingestion.

Decide how to withdraw products, expire promotions, and handle unavailable images. A failed partial update should not silently publish zero prices or mark every item as available. Reconcile record counts and failures after each run. Store an export version or timestamp so an incident can be traced to the data that was sent.

Feed discovery is not transaction permission

A catalog entry can explain an offer. It cannot authorize an agent to spend a customer's money. Merchant approval, checkout support, geographic availability, payment authorization, and final confirmation must be established separately. Start with the platform's merchant participation information and your actual account configuration.

If checkout remains on your website, ensure the destination retains the selected product and makes price, shipping, and confirmation clear. A well-functioning web handoff can be a useful result without claiming a native purchase inside every assistant.

A practical release gate

Release when identifiers are stable, required fields are valid, sample variants reconcile, stale-data behavior is defined, rejected records are visible to an owner, and the actual next step works. Keep the report small enough to inspect after a routine catalog update. The feed validation recipe provides a machine-readable review structure; the commerce readiness guide covers what happens after selection.