Blog · Agents and commerce

Shopping inside ChatGPT, and what it reads

Published 21 August 2026 · Updated 8 October 2026 · 7 min read

Shopping inside ChatGPT, and what it reads
Photograph: Bruno Kelzer / unsplash

The short answer: ChatGPT learns about a product in two separate ways, and they are not interchangeable. One is a crawl of your product page by a named bot, which reads whatever your HTML says and guesses the rest. The other is a structured feed you submit on purpose, with nine required fields per item, which is also the only route that can end in a purchase without the buyer leaving the chat. A catalogue can sit in the first route and be absent from the second without anyone having decided that.

Why: the crawl route needs nothing from you, while the feed route has to be applied for and then operated. Everything below is sourced to OpenAI's own commerce and crawler documentation as it read on 8 October 2026. We have not operated the feed route on a live catalogue of our own, so this post describes what the specifications require, not what we have measured them to do.

Two pipes, different payloads

The crawl route is the one you already have. OpenAI publishes its bots and their user agent tokens: OAI-SearchBot/1.4 surfaces pages in ChatGPT's search features, ChatGPT-User/1.0 fetches a page when a user's question needs it, and OAI-AdsBot/1.0 checks landing pages submitted as ads. Each has a published IP list. The documentation also carries a line worth reading twice: because ChatGPT-User requests are started by a person, robots rules may not apply to them the way they apply to a training crawler.

The feed route is something you apply for and then operate. It is defined in OpenAI's commerce specifications, and the minimum viable item carries item_id, title, description, url, brand, seller_name, image_url, availability and price. Availability is an enumeration, not free text: in_stock, out_of_stock, pre_order, backorder or unknown. Titles are capped at a recommended 150 characters and descriptions at 5,000. Optional fields such as gtin, condition, sale_price, star_rating and return_deadline_in_days are described as improving answer quality without being required for ingestion.

Notice what the feed gives the model that a page does not hand over cleanly. A stable identifier. A seller distinct from a brand. An availability state that is machine readable rather than inferred from a greyed-out button. When you compare the two pipes, the feed is not a copy of the page. It is a different and much less ambiguous description of the same object, which is the argument made at more length in Agentic commerce: what an agent needs from your catalogue.

The flags nobody reads

Two defaults in the feed specification decide more than most optimisation work does.

Search eligibility is on by default, controlled per item by is_eligible_search, so an item you submit is a candidate for answers unless you say otherwise. The feed specification is careful to add that eligibility does not guarantee display, and we cannot see what decides display. Checkout is the opposite flag. The specification describes it as conditionally required and off unless you opt in, and it takes effect only where search eligibility is also true and checkout is enabled for the integration. A catalogue can therefore be fully ingested, well described, eligible, and still incapable of completing a sale inside the conversation, which is a configuration fact rather than a ranking one.

The cadence guidance is plain and easy to skip. OpenAI's get started guide recommends providing the entire feed once a day by file upload and sending updates through the API during the day, or doing both by API if the catalogue is small enough. A nightly full export with no intraday updates means the price and stock you have submitted can be up to twenty-four hours behind your own systems, which for a fast-moving catalogue is the gap between a correct recommendation and a customer arriving at a sold-out page. What the surface actually shows a buyer at a given moment is not something we can observe from outside.

What buying actually requires of your systems

The checkout side is not a feed field. It is five REST endpoints your commerce stack has to serve: POST /checkout_sessions to open a session, POST /checkout_sessions/{id} to update address, fulfilment or items, /complete to finalise with payment, /cancel to kill it, and a GET to read current state. The specification pins two status codes worth noting: create responses should return 201, and cancelling a session that is already completed or cancelled should return 405.

The headers are where engineering time goes. Every request carries Idempotency-Key, Request-Id, a Base64 HMAC Signature, an RFC 3339 Timestamp and an API-Version pinned to a dated string such as 2025-09-12. Each response must return the full cart state, with line items, taxes, fulfilment options and totals, because the agent displays and validates against what you return rather than against anything it remembers. Order lifecycle webhooks keep the two sides honest after the sale.

Read that list as a staffing question rather than a marketing one. Signed, idempotent, versioned endpoints with webhook callbacks are platform work on a release train, not a content change. This is the boundary dispute described in Who owns AEO inside a company, and it is one reason a feed can sit half-built while everyone agrees it matters.

The protocol itself is published as the Agentic Commerce Protocol under the Apache 2.0 licence, with OpenAI named as the first AI platform to implement it and Stripe as the first compatible payment processor, so your platform team can read the specification today rather than wait for a partnership call.

A check you can run this week

You do not need a tool for the first pass. Pick five products that matter and do this.

Fetch the product page with JavaScript disabled, the way a text browser would, and read what comes back in source order. If price, availability and brand are not in that text, the crawl route is guessing. Then compare that text against the nine required feed fields and write down which ones a machine could extract unambiguously and which ones it could not. Seller name and a stable per-variant identifier are the two we would check first, because the feed specification requires both and ordinary product HTML has no standard place to carry either.

Next, check your logs for OAI-SearchBot and ChatGPT-User against those five URLs over thirty days. Being fetched is not being recommended, but never being fetched settles the question. Finally, ask ChatGPT a buying question using the plain noun for your category and look at whether a shopping surface appears at all. The feed specification is written for purchasable items and variants carrying a price and an availability state, so categories that do not fit that shape have nothing to submit. We cannot tell you what the shopping surface does for them, only that the documented route does not describe them. The self-check lists ten of these in the same spirit.

The markup side of the crawl route is a separate job with its own failure modes, covered in Product schema for AI shopping answers. Whether an agent can get further than looking, into a basket or a booking form, is covered in Can an agent book, buy or fill your form.

Honest limits

This post establishes what OpenAI's published specifications require. It establishes nothing about outcomes. We cannot see ranking: nothing published says how eligible offers are ordered, and the feed specification states plainly that eligibility does not guarantee display. We have not operated a feed or a checkout integration ourselves, so we carry no measurement of how long ingestion takes, how often a shopping surface appears, or what a feed does to sales, and we have removed the figures we could not trace to a source a reader can open.

Two further gaps. We have no reliable attribution from an in-chat purchase back to a campaign, because we cannot observe what the surface passes to an analytics stack. And the specifications move: the dated API-Version string in the checkout headers exists because they expect to change, so treat everything here as true of the documentation on 8 October 2026 and read the source before you build against it.

FAQ

Does my product need a feed to appear in ChatGPT at all? No. The crawler documentation describes OAI-SearchBot surfacing sites in ChatGPT's search features independently of any feed. The feed changes what the model is told rather than left to infer, and the purchase path requires it, but being mentioned does not.

Can I block training crawlers and still appear in shopping answers? The documentation says the settings are independent, and gives allowing OAI-SearchBot while disallowing GPTBot as its own example. It also warns that a site opted out of OAI-SearchBot drops out of ChatGPT's search answers while remaining available as a navigational link.

Why is my item in answers but has no buy button? The feed specification leaves checkout eligibility off unless you opt in, and the opt-in applies only where checkout is enabled for the integration. We cannot see which card a given answer chooses to show, so treat a missing button as a configuration question first.

How often should the feed update? OpenAI's get started guide recommends providing the entire feed once a day by file upload and sending updates through the API during the day. Price and stock are the fields where staleness costs you most.

Sources

Related reading

Agentic commerce: what an agent needs from your catalogueCan an agent book, buy or fill your formProduct schema for AI shopping answersWho owns AEO inside a companyStock, availability and answers that go staleMCP servers for brands: a practical look