The same shopping experience can hide opposite architectures
An agent receives one request:
It searches products from several merchants, compares price and availability, and presents a shortlist.
From the user’s perspective, the system looks like one catalog. Behind the interface, that catalog can be created in two fundamentally different ways.
One platform may already operate every participating store and product record. Alternatively, a network may coordinate stores that remain independently hosted and governed.
Shopify is increasingly building the first model. A federated WooCommerce network must build the second.
Shopify’s advantage is centralization
Calling Shopify “federated by nature” would be technically imprecise. Federation normally describes coordination among autonomous systems.
Shopify has a stronger starting position for this particular problem: it is a centrally operated, multi-tenant commerce platform. Merchants remain separate businesses, but their catalogs run inside a common platform model.
That gives Shopify several assets before an AI channel makes its first request:
- a shared product and variant schema;
- platform-level merchant and product identities;
- a standard product taxonomy;
- central access to price and inventory updates;
- one administrative surface for channel permissions;
- an existing merchant population.
Shopify can therefore build a global catalog as a native platform capability rather than negotiating an integration with every merchant installation.
The current Shopify developer documentation exposes this distinction directly. Its Global Catalog searches across Shopify merchants; its Storefront Catalog is scoped to one merchant. Both implement the UCP Catalog capability and expose the same core search and lookup model.
- one control plane and product model;
- native merchant population;
- aggregation is a platform capability.
- independently operated stores;
- local Bridge nodes and explicit opt-in;
- aggregation must be coordinated.
Shopify Catalog is more than a feed
Shopify describes Catalog as a structured source of product information from eligible merchants. It maps products to the Shopify Standard Product Taxonomy, enriches attributes and can cluster equivalent products across stores. Agents can search the global catalog or look up a known product for current details.
Its developer surface now includes a Global Catalog MCP endpoint:
https://catalog.shopify.com/api/ucp/mcp
A separate store-scoped endpoint is available under the merchant domain:
https://{storeDomain}/api/ucp/mcp
This is the distinction the WooCommerce federation series has been working toward: local and global catalog access expressed through related contracts.
Shopify can provide both because the local and global layers are controlled by the same platform.
Why Shopify merchants can appear with little integration work
OpenAI states that product data for Shopify merchants is already integrated into ChatGPT through Shopify Catalog and that no additional integration work is required from individual merchants. That statement applies within eligibility, market and channel controls; it does not mean every product is guaranteed to appear.
Shopify likewise says eligible products can be included without constructing a separate feed for every agent channel. Merchants manage product information in Shopify, while the platform handles structuring, enrichment and syndication.
This is a substantial distribution advantage.
When a new agent connects to Shopify Catalog, it does not begin with an empty network. The platform already knows participating stores and products. It can apply one taxonomy, one eligibility system and one access policy across them.
WooCommerce begins from the opposite topology
WooCommerce is an open-source plugin installed on independently operated WordPress sites.
Two WooCommerce stores may share core software while differing in almost everything around it:
- hosting and network controls;
- WooCommerce and WordPress versions;
- brand and attribute plugins;
- taxonomies and product conventions;
- inventory integrations;
- caching and security layers;
- privacy and distribution choices.
No central WooCommerce runtime possesses every merchant’s current catalog by default. No platform-wide control plane can automatically decide that an independent store has joined a new discovery channel.
This is not a missing API endpoint. It is a consequence of the ownership model.
Decentralization creates an integration tax
WooCommerce’s independence gives merchants control over infrastructure and extensions. The cost is coordination.
To create a cross-merchant catalog, someone must:
- make each store expose a compatible public contract;
- discover participating stores;
- obtain and enforce merchant consent;
- normalize identities, categories and commercial fields;
- handle stores that fail independently;
- build an index without becoming the checkout authority;
- earn the initial merchant network one installation at a time.
Shopify internalizes much of this cost at platform level. A WooCommerce federation must pay it explicitly.
The Bridge is a local control plane
KaliCart Bridge does not turn WooCommerce into a centralized SaaS platform. It gives one independently operated store a declared machine-facing boundary.
The merchant-side node can state:
- where its catalog endpoints are;
- which filters and representations it supports;
- how price, stock and variations should be interpreted;
- which product-data defects are known;
- whether federation is permitted;
- where checkout and final authority remain.
The Bridge is therefore not only a data formatter. It is the smallest control plane that an independent merchant needs in order to participate in a larger network without handing over administrative credentials or relocating its catalog.
Global coordinates; it does not own the stores
Once several Bridge nodes expose the same contract and opt in, KaliCart Global can create a cross-merchant index.
The central layer still exists. Federation does not mean the absence of coordination. Global operates a registry, canonical routing and a shared search surface.
The difference is what that central layer controls.
It may:
- discover and ingest consenting nodes;
- map merchant categories into shared routes;
- return cross-merchant candidates;
- record provenance and observation time;
- remove a merchant when consent is revoked.
It should not:
- edit the merchant’s WooCommerce data;
- invent missing commercial facts;
- become the authority for the final checkout total;
- require the local Bridge to stop working when federation is disabled.
This is interoperability through protocol rather than interoperability through shared ownership.
Centralization is not merely a business constraint
Technical discussions sometimes treat centralization only as a political or commercial concern. For catalog infrastructure, it also produces measurable engineering benefits.
A central platform can coordinate schema migrations, deploy fixes, enforce minimum fields and update every participating catalog surface. It can use one identity system and observe network-wide failures. It can introduce a new agent channel without asking each merchant to install software.
Those advantages are real. A federated architecture should acknowledge them rather than pretending decentralization is free.
| Dimension | Central platform catalog | Protocol federation |
|---|---|---|
| Merchant onboarding | Native for eligible stores | Node installation and opt-in |
| Schema consistency | One platform controls the model | A contract aligns heterogeneous stores |
| Initial network effect | Existing merchant base | The cold start must be earned |
| Infrastructure control | Platform-operated runtime | Store remains independently operated |
| Failure and governance | Coordinated platform-wide policy | Partial failure and explicit consent |
This is an architecture comparison, not a product ranking. The trade-off is coherence versus independence—not modern versus obsolete.
Federation protects different values
The costlier federated path exists because independent operation has value too.
A merchant can retain:
- its own hosting and database;
- its preferred WooCommerce extensions;
- its customer relationship and storefront;
- control over whether Global may ingest the catalog;
- the ability to revoke network participation while preserving local access;
- portability beyond one commerce platform’s agent ecosystem.
The architecture does not guarantee that these advantages outweigh Shopify’s convenience for every business. It gives merchants a different trade-off.
The cold-start difference is decisive
Shopify’s central catalog begins with a platform-scale merchant base. A new federated WooCommerce catalog begins with zero nodes.
This changes the go-to-market problem.
Building the protocol is not enough. The network must recruit merchants, prove that agents use the catalog and create enough coverage for cross-merchant search to be useful. Until then, the local Bridge may be technically valuable while the federated layer remains economically small.
This is the most important disadvantage to state honestly. A federation does not inherit a network effect from the openness of its protocol. Participation must be earned.
“Open” and “closed” are too blunt
Shopify Catalog is centrally operated, but Shopify says its catalog interface is available to agents beyond a closed list of major partners. It also implements UCP, an open protocol.
WooCommerce is open source, but an individual store can still block clients, expose inconsistent data or remain impossible to discover.
The useful distinction is therefore not simply open versus closed.
It is:
- Who operates the control plane?
- Who defines the product model?
- How does a merchant join or leave?
- Where does the catalog remain authoritative?
- Who bears the coordination cost?
The strategic difference
Shopify’s agentic-commerce advantage is not that its APIs are inherently more intelligent. The platform already has the organizational position required to aggregate its merchants.
WooCommerce has no equivalent central position by design.
A WooCommerce Bridge and federation therefore perform work that Shopify can do internally:
Shopify:
shared platform → shared catalog → agent channels
WooCommerce:
independent stores → shared edge contract → optional federation → agent channels
The second path is longer. It is also the path that preserves independent deployments.
What KaliCart is actually trying to reproduce
The goal is not to rebuild Shopify around WooCommerce.
It is to reproduce three useful properties of a platform catalog:
- one contract that agents can understand;
- one optional surface for cross-merchant discovery;
- one path back to current merchant-authoritative product data.
But it tries to do so without requiring one company to operate every merchant’s storefront or database.
That is not automatically better. It is the substantive architectural difference.