THE SHORT ANSWER
The checked Stable product specification lists nine basic discovery fields: item_id, title, description, url, brand, seller_name, image_url, availability and price. Use this as an ownership checklist, then consult the live specification for exact types, allowed values and conditional requirements.
Assign an owner to each basic fact
Group the fields by responsibility. Product identity and descriptive content usually belong with catalog ownership. Price and availability need a dependable commercial source. Seller context needs confirmation from the merchant or marketplace operator. Your actual organization may assign those responsibilities differently; make the assignment explicit.
A required field being present is only the first check. The value can still describe the wrong item or seller. Ask how the team will verify the meaning, not merely whether the cell is empty. This avoids a common pattern in which a converter fills all nine fields but weakens trust in the result.
Review one exact purchasable item
Select a variant and read its source row alongside the product page. The title, description, URL and image should refer to that selection. Price and stock should belong to the same offer, in the intended market and currency.
Save that comparison as an example for the rest of the team. It becomes a useful reference when someone later asks whether a field should describe a parent product, a variant or the store. Those scope questions create more trouble than many simple formatting errors.
Make unknowns visible before release
Keep a gap list with the missing fact, its owner and the evidence needed to resolve it. Do not turn unknown brand, seller or stock information into a confident claim just to remove an error message. A local check should help identify the next action rather than conceal uncertainty.
Where the target allows a particular explicit value or omission behavior, follow that documented rule. Do not apply a generic replacement such as n/a across every field. Different types and fields carry different meanings, and a universal placeholder can introduce new problems.
Add operational evidence around the schema
After checking the sample, document how the same facts will stay current. Record the source snapshot, mapping version and review decisions. Include an unavailable item and a changed price in the next test so the workflow demonstrates an update rather than only an initial export.
A small website checker can help spot basic missing values in a Merchant Center-style sample. It does not reproduce the complete OpenAI validator or establish onboarding approval. Use the official Stable reference and your destination agreement when preparing a production integration.
ILLUSTRATIVE WORKED EXAMPLE
Make it concrete.
Illustrative responsibility sheet: merchandising owns item identity, title and description; the commerce platform owns price and stock; the merchant confirms seller context. One row still has no verified brand, so the sample is held for that sourcing decision rather than filled with the store name.
Your practical checklist
- Assign owners to all nine basic facts.
- Review one selected variant end to end.
- Check meaning as well as presence.
- Keep unknowns in a visible resolution queue.
- Test an update after the first sample.
Common questions
Are these all possible feed fields?
No. They are the basic discovery fields. Optional and conditional data, Ads and checkout requirements need their own review.
Does passing this checklist prove acceptance?
No. The checklist supports preparation; the destination’s current schema, onboarding and ingestion checks remain authoritative.
Sources & scope
Official references checked 29 October 2026. Examples are illustrative, not customer results. Platform requirements can change; use current destination documentation for implementation decisions.
Our editorial method & corrections ↗