Many explainers describe the Universal Commerce Protocol as live-only: an agent asks a store's catalog a question and gets today's answer, with no product feed in between. That has been true of the released spec. It may not stay true.

On 25 September Shopify's Ilya Grigorik opened PR #866, a working draft from the Bulk Product Discovery working group. It lets a business publish its whole catalog as files that a platform can index ahead of time, then check price and stock live when a buyer is actually looking. This post covers what the draft proposes, how it works, what reviewers are pushing back on, and what it means for stores.

It is a draft. Nothing here is in a released version, and the details below can change in review.

#What is a UCP catalog feed?

A UCP catalog feed is a bulk copy of a store's catalog, published as files: the same Product records that UCP's catalog search returns, written out in full so a platform can index, embed and rank them offline. At serving time the platform still calls catalog search and lookup for the authoritative price and availability.

The draft puts the split in one line: "the feed is point-in-time, the live operations are authoritative."

That answers a real gap. Live search works well when an agent already knows which store to ask. It doesn't help a platform that wants to know what thousands of stores sell before a buyer asks anything. Today that comes from feeds outside UCP, such as Merchant Center. The working group's charter is to bring that path into the protocol, using UCP's own product shape.

#How the draft works

The draft is built from pieces UCP already has. There are four layers:

/.well-known/ucp        capability declared beside search and lookup
  → feed endpoint       feed list, per caller (public or authenticated)
    → feed entry        one per market: id, format, interval, generated_at
      → manifest        one per snapshot, never changed once published
        → files         gzipped JSON Lines or Parquet, with a digest per file

Discovery. A store declares the feed capability in its UCP profile, with one config.endpoint URL. That is the only feed URL in the profile. Every other URL is trusted because that endpoint returned it, not because of its hostname, so files can sit on a CDN or a feed manager's servers.

The feed list. The endpoint returns the feeds available to whoever is asking. An anonymous request gets the store's public feeds, if any. An authenticated platform gets the feeds the store has set up for it, using the authentication UCP already defines (API key, OAuth, mTLS or signed requests). A store that wants to give its ad crawler and its search crawler different feeds does it by caller identity, not by request parameters.

One feed per market. Each feed is resolved for one market context: country, language and currency. Canadian English and Canadian French are two feeds. The draft says a catalog feed should not be scoped by anything that describes a buyer rather than a market, such as location or eligibility. Those still come from live search.

Manifests and snapshots. Each feed entry points to a manifest that lists the files in one snapshot. A snapshot is complete as of its generated_at time and never changes once published. A correction is a new snapshot. Each file can carry an RFC 9530 digest so the platform can check it downloaded the bytes intact.

Two formats. The draft registers jsonl+gzip (one Product per line) and parquet. A platform must support both. The draft's reasoning: a platform is one implementation and businesses are many, so the obligation sits with the platform.

#Three rules that matter for stores

Absence means "not offered", for any reason. When a platform applies a complete snapshot, it replaces its old copy. A product missing from the latest snapshot is not offered in that market, and the draft says outright that sold out, unpublished, filtered and deleted look the same. A platform that couldn't fetch every file, or found a digest mismatch, must keep its old copy rather than treat missing products as removed.

Supplemental feeds layer on top of a base. A store can publish a small feed that only changes some fields of a base feed, joined on product and variant id. The draft's examples: Canadian prices laid over a US feed every two hours while the full catalog rolls daily, and extra compliance fields that only one marketplace asks for, sent only to that marketplace. A supplement can change fields but can't remove a product from the base.

The store's identifiers stay the store's. Records must carry the same product and variant IDs that the store's catalog lookup resolves. A feed manager publishing on the store's behalf may add its own IDs but must not replace the store's. If it does, the platform finds out at serving time, when lookup returns not_found.

#What reviewers are raising

The PR has had six reviews from four reviewers, all comments rather than approvals. Most of the debate is about adoption, not the design.

• Existing feeds. Greg Smith (Google, a working group co-chair) noted that virtually every merchant already exports a Merchant Center TSV or XML feed. Making them turn flat variant rows into nested UCP Products first "will slow adoption". He sketched how a manifest could declare a mapping from an existing feed format to UCP. James Andersen (Meta, also a co-chair) read the draft as already allowing that, through an extension that registers its own format value.
• Changing feeds in place. Alex Jansen (Google) pointed out that many merchants edit feed files in place, sometimes a single cell, at a fixed URL that Merchant Center fetches on a schedule. Writing a new manifest and snapshot for every small change "seems expensive and not compatible with current practice".
• Naming. Smith also flagged that extends means two different things in the same document: capability inheritance in one place, "this feed overlays that one" in another.
• Terms of use. Francesco Marinoni Moretto asked for a way for a store to say what its records may be used for (search indexing yes, model training no, kept for how long), noting that expires_at controls how long the files stay available, not how they're used. He suggested reusing UCP's links[] and policies[], and the IETF's AI preferences vocabulary.
• Deltas. Another contributor posted a schema for incremental updates. The draft lists delta snapshots and push notifications as future work. That matches the working group's three-phase roadmap from its 9 September meeting: discovery and market feeds first, then deltas, then push.

One structural point is worth watching. The draft splits the mechanism in two: a general dev.ucp.common.feed capability, and dev.ucp.shopping.catalog.feed as the extension that makes the records Products. The working group's 16 September notes record a decision to keep the feed capability in the shopping catalog namespace rather than promoting it to a common one. The PR's second commit is titled "split into common feed and shopping overlay". Minutes after 16 September haven't been published yet, so we can't tell from the public record whether the group revisited that. Reviewers asked what other record types a common feed would carry; James Andersen suggested locations and promotions.

#What the working group has already settled

From the published minutes, a few positions sit behind the draft:

• No inventory counts in the core feed. Greg Smith said on 16 September that leaving quantities out is deliberate: a point-in-time feed can't be an accurate inventory source. An optional extension for cases such as B2B order quantities may follow.
• A static handshake and a dynamic endpoint. The feed is declared in the existing well-known profile, and feed lists come from a separate endpoint that uses UCP's existing authentication.
• No on-demand feed generation in the baseline, on complexity and abuse grounds.
• Feedback to stores is open. Three options were on the table on 9 September: structured messages, a generic feedback API, or a contact address in the profile. The draft doesn't pick one.

#What this means for stores

If the draft lands in roughly this shape:

1. Your feed and your live catalog have to agree. The same IDs, the same Product shape. A platform will index from the feed and confirm through lookup, so a gap between the two shows up as products that can't be resolved.
2. Hosted platforms and feed managers will likely do most of the work. The draft lets someone other than the store run the feed endpoint, and the working group's leading direction for existing feed formats is adapters maintained by platforms or feed services. Channable and Feedonomics are on the group's member list.
3. Your existing feed isn't wasted. The adoption debate in review is about exactly that: how much of today's Merchant Center-style feed can carry over.

The working group's charter page gives a target completion of late October 2026. A feed capability would then still need Shopping Tech Council approval and a release.

#FAQ

Does UCP support product feeds? Not in a released version. PR #866 is a working draft that adds a catalog feed capability, dev.ucp.shopping.catalog.feed, on top of a general feed capability, dev.ucp.common.feed.

Does a feed replace live catalog search? No. The feed is for indexing ahead of time. A platform still calls catalog search and lookup at serving time for current price and availability.

What formats does the draft use? Gzipped JSON Lines (jsonl+gzip) and Parquet. A platform must support both. Extensions can register other formats.

Can I keep using my Merchant Center feed? The draft as written expects UCP Product records. Reviewers from Google have asked for a path from existing TSV and XML feeds, and one suggested route is an extension that registers its own format. That's still being discussed.

Can a store make its feed private? Yes. The feed endpoint can be public or require platform authentication, and each platform gets the feed list the store has set up for it. For private feeds, manifest URLs must be unguessable.

When will it ship? The working group targets late October 2026 for its work. After that it needs Shopping Tech Council approval and a UCP release. No release date is set.

#What we'll watch

We'll follow #866 through review and note when it merges. When a business first declares a feed capability in a live UCP profile, we'll say so.

If you're building a catalog endpoint now, the catalog validator checks the Product records your search returns, which are the same records a feed would carry.

#About UCP Checker

UCP Checker is the independent validation and observability layer for the Universal Commerce Protocol. We crawl, validate and grade every public UCP manifest we can find, run the merchant directory, the UCP Score, live adoption stats, the vertical guides and the authority-bound vendor map, and track the spec as it evolves so you don't have to — measured from two vantages (what a business declares, and what actually happens when an agent transacts), the same way for everyone, without picking winners.

#Sources

• PR #866: feed capability for bulk catalog access, draft, opened 25 September 2026, open
• Bulk Product Discovery DWG minutes, 9 September 2026
• Bulk Product Discovery DWG minutes, 16 September 2026
• Bulk Product Discovery DWG page, charter, chairs and target date
• Issue #682: Domain Working Group (DWG) Charter: Bulk Product Discovery, open
• Issue #550: RFC: A Bulk Product Discovery Layer for UCP, open
• Catalog capability (draft docs), ucp.dev
• RFC 9530: Digest Fields, IETF

Related coverage: UCP's first Domain Working Group starts with product feeds · Video, 3D and image variants in UCP · Catalog validator · UCP for Retail