Loading...
Loading...
The Universal Commerce Protocol shipped its largest release yet on April 8, 2026. Cart, Catalog, Identity Linking, signed requests, and what merchants need to migrate.
On April 9, 2026, the Universal Commerce Protocol Tech Council published version 2026-04-08 of the UCP specification. It is the largest single release in the protocol's short life — three new capabilities, a signing layer for requests and responses, tighter negotiation rules, and dozens of smaller cleanups. If you implemented UCP at NRF 2026 against the original 2026-01-23 spec, this is the update that turns UCP from a polite handshake into an actual shopping environment.
This is a practical migration guide. We will walk through what changed, why each change exists, what merchants have to update, and what their platforms quietly take care of for them.
When Google and Shopify announced UCP in January, the protocol shipped with a useful but narrow Checkout capability. An AI agent could create a checkout for a single product, collect shipping and tax, and complete payment through Google Pay. That covered "buy this one thing" cleanly. It did not cover the rest of how people actually shop.
Version 2026-04-08 fixes that with three new capabilities, all previewed in Google's March update post and now formalized in the published spec.
Cart. Lets an agent assemble a multi-item basket on a single store, save it, and hand it to the Checkout capability when the shopper is ready. Cart supports add, update, remove, and lookup operations, and it is the capability behind the new Cart experience in Google AI Mode.
Catalog. Two related operations — search_catalog and lookup_catalog — let agents query a merchant's live catalog for product details, variants, inventory signals, and pricing. Until now, agents had to rely on snapshot product feeds (the model that ACP uses) or scrape the storefront. Catalog gives agents a structured, real-time view of what is actually buyable right now.
Identity Linking. An OAuth 2.0 flow that ties a shopper's authenticated session on the agent surface to their account at the merchant. Once linked, the agent gets the same loyalty tier, member pricing, saved addresses, and free shipping treatment that the shopper would get logging in directly.
Google's framing of these three was that UCP needed to "make online shopping easier and more connected," in the words of Ashish Gupta, VP/GM of Merchant Shopping. In practice, Cart and Catalog cover the missing top of the funnel; Identity Linking covers the missing personalization layer. Together, they make UCP look much more like a real storefront and much less like a single-product widget.
The single most consequential change for security teams is request and response signing. Every UCP profile now publishes JSON Web Key (JWK) entries for the keys the party uses to sign payloads. Both businesses and platforms can sign their requests, and the receiving side can verify the signature against the published JWK.
This matters for two reasons.
First, it lets a merchant prove which agent is talking to them, even without a shared API key. The agent's profile lives at a known URL on a domain it controls; the keys are published there; the signature on every request is verifiable. That is the same trust model TLS uses for the web — public keys at well-known locations, signed traffic in between.
Second, it is the substrate that the AP2 Mandates extension builds on. AP2 (Agent Payments Protocol) requires cryptographically signed CheckoutMandates and PaymentMandates — tamper-proof records that the user authorized this exact transaction with this exact agent. Without a signing layer in the underlying transport, AP2 cannot bind those mandates to the actual checkout state. The April spec quietly puts that substrate in place across UCP, even for merchants who never enable AP2 directly.
The other architecturally important change is in how extensions compose. UCP has always allowed extensions — discounts, loyalty, fulfillment, AP2 mandates, and so on — to extend a base capability. The 2026-01-23 spec assumed each extension extended exactly one parent. That breaks down when, for example, a single loyalty extension wants to add fields to both Cart and Checkout.
Version 2026-04-08 introduces multi-parent support: an extension can declare that it extends multiple capabilities, and define different fields per parent. The spec uses deterministic schema definition keys (matching parent capability names) to keep the resulting schemas unambiguous. The intersection algorithm — the part that figures out, for each request, which capabilities and extensions both sides understand — was rewritten to prune orphaned extensions whose required parents are missing or below the minimum version.
For merchants, this is invisible. For people writing extensions (loyalty providers, BNPL handlers, regional tax modules), it is the difference between maintaining one extension or three.
A few changes are small in spec text but easy to trip on.
currency is now required on Order. Before April 8, you could return an Order without an explicit currency code if the rest of the response was unambiguous. Now currency is required on every Order response. If you build orders by composing partial objects, double-check that currency is present on every path.
available_instruments on payment handlers. Payment handler configurations now declare which instruments they actually support in the current cart context. This lets agents filter out, for example, a Klarna handler that does not support the cart's total or country before showing it to the shopper. If you publish payment handler configs, add available_instruments and populate it dynamically.
Intent field on capability negotiation. Agents can now declare a high-level intent ("research", "buy", "reorder") at negotiation time, which lets businesses tune which capabilities and extensions to surface. It is optional, but the higher-quality agent surfaces are starting to use it.
Spec error handling. UCP negotiation failures now have a defined error model with stable codes, instead of returning generic 4xx responses. If your client code did string matching on error bodies, switch to the new codes.
ec_color_scheme query parameter on embedded checkouts. This is the smallest possible change with a real visible effect — the Embedded Checkout Protocol now accepts a color scheme hint so the merchant's checkout iframe can render dark mode when the host AI surface is dark.
If you sell on Shopify, on Salesforce Commerce Cloud, or via Commerce Inc, you almost certainly do not need to hand-edit your /.well-known/ucp manifest. All three were named by Google as platforms implementing the new UCP capabilities, and all three have already started rolling out the 2026-04-08 schema to their merchants.
Shopify announced on April 22 that the Storefront Catalog MCP now implements the UCP Catalog capability, with three new tools — search_catalog, lookup_catalog, and get_product — conforming to the v2026-04-08 schema. The previous tool versions are kept alive until June 15, 2026, giving developers a roughly two-month migration window. The endpoint moved to https://{storedomain}/api/ucp/mcp, which makes the Catalog implementation explicitly UCP-shaped rather than a Shopify-only convention.
Hydrogen stores on Oxygen received the new Storefront MCP and Catalog as part of the Winter 2026 Edition. Standard Shopify stores get it pushed automatically.
For platform-hosted merchants, the migration story is therefore short: confirm that your UCP profile validates against the new schemas (run a UCP validator), confirm that orders carry currency, and add the new capabilities to whatever surfaces you control directly (custom apps, headless storefronts, internal agent integrations).
If you publish your own /.well-known/ucp manifest — which is most merchants on WooCommerce, custom-built storefronts, and a long tail of platforms — here is the practical sequence.
Most of these steps take an afternoon for a well-instrumented merchant. The Cart and Catalog work is the longest pole — Cart needs persistent cart storage exposed over UCP, and Catalog needs structured search you trust enough to expose live to agents.
It is worth listing what version 2026-04-08 deliberately did not change, because some merchants asked for these and did not get them.
The Tech Council's stated focus for the next release is "scaling capabilities," which most observers read as expanding Catalog, formalizing Loyalty as a first-class capability, and bringing more payment handlers online. Those are open issues, not committed scope.
Specs do not get headlines. The 2026-04-08 release got one anyway, because the gap between "UCP can do single-item checkout in Etsy" and "UCP can run a real cart with real loyalty pricing across thousands of merchants" is the gap UCP needed to close to be taken seriously by enterprise retailers.
It is also the first release shipped under the expanded UCP Tech Council, which on April 24 added Amazon, Meta, Microsoft, Salesforce, and Stripe alongside the founding members Google, Shopify, Etsy, Target, and Wayfair. That governance layer is what makes 2026-04-08 a credible single source of truth for cross-platform agentic commerce, instead of a Google-and-Shopify side project.
For merchants, the practical takeaway is simple. If you implemented UCP for NRF and never touched it again, the spec moved underneath you. The good news is that most of the heavy lifting happens at the platform layer. The less-good news is that the gap between platform-managed UCP and self-managed UCP is now wider than it was in January, and self-hosted merchants who do not migrate will be left running an obsolete dialect of the protocol by the summer.
Browse the UCP merchant directory to see who is already shipping the new capabilities, or audit your own store to see how it looks against the 2026-04-08 schema today.
The current published version is 2026-04-08, released on April 9, 2026. UCP uses date-based versioning (YYYY-MM-DD) so chronological ordering is unambiguous. The previous published version was 2026-01-23, which is what most early UCP merchants implemented.
Three new capabilities (Cart, Catalog search, and Catalog lookup), request and response signing, multi-parent extension support with deterministic schema resolution, an intent field on capability negotiation, and tightened error handling for negotiation failures. The release also makes currency required on Order and adds an available_instruments field to payment handler configurations.
In most cases no. UCP versions component capabilities independently, so you can keep declaring the older Checkout schema while opting into the newer Cart and Catalog capabilities. The intersection algorithm picks the highest mutual version per capability and prunes any extension whose required minimums are not met.
At launch in January 2026, UCP checkout was effectively a single-item guest checkout. The Cart capability lets an agent build a multi-item basket, persist it, and hand the assembled cart to the Checkout capability for tax, shipping, and payment.
Update the version field in your /.well-known/ucp manifest, add the Cart and Catalog capabilities if you want to support them, generate and publish signing keys as JWKs, mark currency as required on every Order response, and add available_instruments to each payment handler. Most merchants on Shopify, Salesforce Commerce Cloud, or Commerce Inc do not have to do any of this manually.
Tools like ucpchecker.com and Google's Merchant Center sandbox both validate /.well-known/ucp manifests against the published schemas at ucp.dev.
Discover the merchants powering autonomous commerce with the Universal Commerce Protocol.