Ask five practitioners whether GTIN is required in OpenAI’s product feed and you’ll hear five answers, because the honest answer is conditional: OpenAI documents two parser profiles, and they disagree about identifiers.
In the native OpenAI schema, GTIN is optional. The spec’s field table lists gtin as Optional with the format constraint “8-14 digits; no dashes or spaces.” A feed in OpenAI’s own vocabulary can omit it entirely.
In the Google-compatible profile, GTIN-or-MPN is required by default. Verbatim:
“Provide a validgtinormpnwhen you omitidentifier_existsor set it toyes. Setidentifier_existstonoonly when the product genuinely has no identifier.”
Which profile applies isn’t a guess — the selection procedure is documented. OpenAI samples records from every file and checks its own schema first; the Google-compatible profile is selected “only if it accepts at least one sampled record from each file that yielded records,” and — importantly — “OpenAI uses the selected parser for every eligible file and row. It does not switch parsers from row to row.” So a Shopify/Merchant-Center-style export with id, title, link, image_link… columns lands in the Google-compatible profile, identifier rules included.
One more wrinkle from the Google side, since the same feeds usually serve Merchant Center (and therefore Gemini’s Shopping Graph): Google’s spec grades gtin as “It Depends (strongly recommended if available)” — and warns that a wrong GTIN is worse than a missing one: “If you submit a product with an incorrect GTIN value, your product will be disapproved.” That is why our corrected feeds remove GTINs that fail GS1 checksum validation rather than shipping them.
The takeaway: know which parser your feed hits. Native-schema feeds can ship without GTINs; Google-format feeds need GTIN-or-MPN on every row unless identifier_exists: no is genuinely true. And never ship a GTIN you haven’t validated.