What UCP spec changes mean for merchants

UCP versions are dates. The current one is 2026-04-08. Its predecessors were 2026-01-23 and 2026-01-11.

That sounds like a small stylistic choice and it has a real consequence: a date tells you when something changed and nothing about whether it breaks you. Semantic versioning at least promises that a major bump means incompatibility. Here, 2026-01-23 and 2026-04-08 look equally innocuous, and only one of them was a breaking release.

Accurate as of July 2026.

What has actually shipped

Three tagged releases so far.

2026-01-11, the first tag

Published alongside the protocol's public launch. Mostly documentation, linting and repository setup rather than protocol changes, which is what a first tag usually looks like.

Useful as a reference point. This is the baseline everything else is diffed against, and what anyone who integrated at launch built on.

2026-01-23, breaking, twelve days later

One significant change: a refactor marked as breaking by its own commit, landing twelve days after the first version.

The upstream notes are thin. They record that the release happened and that it breaks compatibility, but not what specifically moved. If you built against the January 11 version, the diff is the only reliable source.

This one is worth remembering for the pattern rather than the contents. A specification this young will break things, and it will not always explain itself well when it does.

2026-04-08, the substantial one

The largest release so far, and the one that makes UCP feel finished rather than provisional:

• Cart as its own capability, so an agent can build a basket across several steps rather than assembling everything at checkout
• Errors as a first-class concept, giving a failed negotiation an agreed shape instead of every implementation guessing
• Request and response signing, so an origin can verify who is calling rather than trusting a header
• Smaller additions: an intent field for relevance, multi-parent schema inheritance with deterministic resolution, a colour scheme parameter for embedded checkouts, available instruments on payment handler configuration, and fulfilment method type becoming optional on updates

Nothing here breaks a working integration. But if you sell anything with a multi-step basket, cart is the reason to revisit.

What this means in practice

Being on an old version is not automatically broken. Profiles declare supported_versions, and the ecosystem is young enough that older declarations are still read. Old is a risk indicator, not a fault.

The version string will not warn you. You cannot look at 2026-04-08 and infer compatibility. You have to know what the release contained.

Breaking changes are not always well documented upstream. The January release is the proof. Release notes are written for implementers of the specification, not for merchants trying to work out whether to panic.

Your platform may move you without asking. If Shopify or another platform publishes your profile, version changes arrive on their schedule. You will not get a release note. This is the most likely way your declared version changes without you doing anything.

Finding out which version you are on

Before any of this matters, you need to know where you stand. One request:

curl -s -H "Accept: application/json" \
  https://yourstore.com/.well-known/ucp \
  | python3 -c 'import sys,json; u=json.load(sys.stdin)["ucp"]; \
      print("declared:  ", u.get("version")); \
      print("supported: ", ", ".join(u.get("supported_versions", {}).keys()))'

Two fields matter. version is what you are telling agents you speak. supported_versions maps versions to version-specific profile URLs, which is how you can serve more than one during a transition.

If those two disagree with what you expect, or if supported_versions lists only a version you have never heard of, your profile is being published by something other than you.

How to keep up without reading every diff

Watch your own declared version. The simplest useful signal. If the version in your profile changes and you did not change it, something upstream moved. A scheduled check catches this.

Read the release, not the tag. When a new version appears, the question is only ever: does this break me, and is there anything I should adopt? We answer exactly that in the UCP changelog, which is why it exists in plain English rather than as a list of tags.

Subscribe rather than remember. The changelog has an RSS feed. A release you find out about six weeks later is a release you found out about too late.

Re-run your validation after any change. Yours or theirs. The validation checklist is quick, and the point is not the first result but noticing when it differs.

What to do when a breaking release lands

1. Check what you declare now. Fetch your profile and read the version. If your platform serves it, this may already have changed.
2. Read what actually broke. Not the tag, the contents. If the upstream notes are thin, as they were in January, go to the diff.
3. Decide whether it touches your capabilities. A change to a capability you do not declare is not your problem.
4. Re-run a conformance check. Cheapest way to find out whether you are still valid.
5. If your platform owns the profile, find out their timeline. You may not be able to act, but you can know.

The wider point

This is the third of the three failure modes that make agent integrations quietly go wrong. Access breaks because your own rules turn agents away. Protocol breaks because a correct-looking profile is unreadable. And drift breaks because the ground moves.

Drift is the one that is guaranteed. The other two you can fix once. This one recurs, and it recurs whether or not anyone on your team touches the code, which is why the answer is a subscription and a scheduled check rather than a task in a sprint.

Read next

• The UCP changelog — every release in plain English, with an RSS feed
• Why agent access breaks silently — the other two failure modes
• How to validate a UCP integration — what to re-run after a change