On April 9th, the UCP Technical Council shipped v2026-04-08 — the first spec bump since January's 2026-01-23 release. It's the largest single release in the protocol's history: 26 new features, 6 breaking changes, 19 documentation updates, and contributions from 15 first-time contributors.
This isn't a patch. It's the release where UCP stops being a checkout-and-order protocol and starts becoming a full commerce platform.
Here's what changed, what it means, and what you should do about it.
The headline features
Carts are now a first-class capability
The most consequential addition is formal cart support (#73). The dev.ucp.shopping.cart capability gives agents the ability to create, read, update, and manage persistent shopping carts — the workflow that dominates human e-commerce but has been entirely absent from agent commerce until now.
We wrote in March that only 2 out of 2,832 verified stores declared cart capabilities. That number was low because the spec itself hadn't formalized the capability. Now it has. The schema defines add-to-cart, remove, quantity updates, and cart retrieval. Discount extensions have been expanded to work with carts too, so agents can apply promo codes before checkout.
For agent developers: this is the capability that unlocks multi-step shopping. Instead of "find product → checkout immediately," agents can now build baskets, compare options, apply discounts, and let the user review before committing. Design for it now, even if adoption will take months to ramp.
Catalog search and product lookup
Agents can now discover what a store actually sells. The new catalog search and product lookup capabilities (dev.ucp.shopping.catalog_search and dev.ucp.shopping.catalog_lookup) give agents structured access to product discovery — search by keyword, filter by attributes, and retrieve full product details including variant IDs.
Previously, agents relied on unstructured HTML scraping or platform-specific APIs to find products before initiating checkout. Now product discovery is part of the protocol itself. This is the missing first step: an agent can search a store's catalog, find what it needs, add items to a cart, and check out — all through UCP.
We've added catalog detection to UCPChecker's capability tracking. As stores adopt these capabilities, you'll see them in the stats and on individual store profiles.
Request and response signing
Cryptographic signing (#156) is the security feature the protocol needed. Stores can now sign responses, and agents can verify they're talking to the real merchant — not a MITM or a spoofed endpoint.
The spec uses JWK-format public keys published in the discovery profile. What's notable is where those keys live: signing_keys has moved from inside the ucp object to the root level of the discovery profile, sitting as a sibling of ucp rather than nested within it. This is a structural change that affects how validators parse manifests.
We've updated our validator to handle both locations — the new root-level position for v2026-04-08+ manifests, and the legacy nested position for older versions.
The structural changes that matter
Business profiles vs. platform profiles
This is the change that will generate the most false positives if your tooling doesn't adapt.
v2026-04-08 formally distinguishes platform profiles (the full spec declarations that platforms like Shopify publish) from business profiles (what individual stores serve at /.well-known/ucp). The key difference: business profiles no longer require spec and schema URLs on capabilities, services, or payment handlers. Those fields are only mandatory at the platform level — stores inherit them from their platform.
This makes sense. A Shopify merchant shouldn't need to declare "spec": "https://ucp.dev/specification/shopping/checkout/" in their manifest — that's Shopify's concern, not the merchant's. But every validator that checked for these fields as required will now throw false warnings against perfectly valid business profiles.
UCPChecker has already updated its validation rules. If your store runs v2026-04-08, we'll validate against the business profile schema — no spurious warnings about missing spec or schema fields that your platform handles upstream. You can verify your store at UCPChecker.com.
Multi-parent capability extensions
Capabilities can now extend multiple parents with deterministic schema resolution. This sounds abstract, but it solves a real problem: capabilities like embedded checkout that need to compose behaviors from both the cart and checkout namespaces.
The extends field on capabilities now accepts an array of reverse-domain names instead of just a single string. Schema resolution follows a defined order, so there's no ambiguity about which parent's definition wins when there's a conflict.
Supported versions for backwards compatibility
Business profiles can now declare a supported_versions field — a map of older protocol versions to their profile URIs. This means a store can advertise "I speak v2026-04-08, but I also have a v2026-01-23 profile at this URL" — letting agents negotiate down to a version they understand.
For the ecosystem, this is important infrastructure. It means the v2026-01-23 → v2026-04-08 migration doesn't have to be a flag day. Stores can support both versions simultaneously while agents upgrade.
The breaking changes
Six changes in this release are marked breaking. Here's what they actually break:
Order schema: currency is now required (#283). Previously optional, the currency field on orders is now mandatory. If your implementation omits it, your order responses will fail validation against v2026-04-08. Fix: add the ISO 4217 currency code (e.g., "USD") to your order objects.
Authorization and abuse signals (#203). Stores can now communicate authorization requirements and abuse indicators to agents. This is new infrastructure for trust — stores can signal "this transaction requires additional verification" or "this request pattern looks suspicious" in a structured way.
Updated order capability (#254). The order schema has been restructured. If you're consuming or producing order responses, check your field names against the updated schema.
Embedded protocol error alignment (#325). Error responses in the embedded checkout protocol now follow UCP's standard error conventions. If you're parsing embedded checkout errors, the shape has changed.
Totals format change (#299). Total amounts now use signed_amount.json — a format that can represent both positive and negative values (for discounts, refunds). If you're reading totals as simple numbers, you'll need to handle the new format.
Identity linking reverted (#329). A previously planned identity linking change was reverted. If you implemented against an earlier draft, verify your identity handling matches the released spec.
What didn't ship
Worth noting what's still in progress. Loyalty capabilities (#251) and return extensions (#257) were tracked for this release but didn't make the cut. The cart capability landed; the full post-purchase lifecycle is still forming.
Per-capability versioning — the ability to bump individual capabilities without bumping the entire protocol — was discussed at the March TC meeting but deferred. The infrastructure for sub-repo versioning is being explored by TC members, but for now, breaking changes still bundle into full protocol bumps.
23 contributors, 15 first-timers
This release had contributions from 23 people, 15 of whom were first-time contributors. The contributor base has broadened beyond the founding companies: documentation fixes from independent developers, schema improvements from payment processors, and tooling contributions from platform teams.
Notable additions: endorsed partners now include Block, Fiserv, Klarna, Splitit, Affirm, and Checkout.com — payment infrastructure companies whose involvement signals where agent commerce payment flows are heading.
What to do now
If you're a store operator: Check your store at UCPChecker.com. We've updated our validation to v2026-04-08 rules, so you'll see an accurate assessment against the new spec. If you're on Shopify, your platform will handle the migration — watch for their update timeline.
If you're an agent developer: Start building for carts and catalog search. These capabilities will roll out through platform-level updates, and when they do, the adoption curve will look like checkout's did — slow for a few weeks, then near-universal overnight. The UCP Playground is the place to test agent interactions against stores that adopt early.
If you're a platform team: The business-vs-platform profile split is the structural change to focus on. Your merchants' profiles just got simpler (fewer required fields), but your platform profile got stricter (spec and schema URLs are mandatory). Review the spec version details and validate your platform-level profile against the new schema.
If you're building tooling: Update your validators. The signing_keys location change, business profile relaxation, and new capability schemas all affect validation logic. We've open-sourced our approach — check the methodology page for how UCPChecker handles version-aware validation.
The bigger picture
v2026-01-23 gave us checkout. v2026-04-08 gives us the rest of the shopping experience: discovery, carts, signing, and the groundwork for trust and authorization. The protocol is filling in the gaps between "an agent can technically buy something" and "an agent can shop the way a human does."
We reported in March that the gap between "has a manifest" (87%) and "an agent can actually buy something" (45% checkout rate) is where the real work lives. This spec release addresses the structural reasons for that gap — not by making checkout better, but by giving agents the capabilities they need for the steps before and after checkout.
We're tracking the v2026-04-08 migration wave across all monitored domains. Check the stats page for real-time adoption data, and subscribe to the weekly report for ecosystem updates as stores begin the transition.
Analysis based on the UCP v2026-04-08 release, published April 9, 2026. UCPChecker validation rules updated same day.
Top comments (0)