UCP (Universal Commerce Protocol) – Definition
Universal Commerce Protocol (UCP) is an open protocol that lets an AI agent discover what a business can do commercially, then transact against it over a standard API. A business publishes a machine-readable profile at /.well-known/ucp declaring its capabilities, service endpoints and public signing keys; an agent fetches that profile, intersects it with its own capabilities, and calls only what both sides support. It was developed by Google with Shopify, Etsy, Target, Walmart, Wayfair and other retailers, and is open source.
A discovery-plus-transaction standard: the store advertises what it supports in a signed profile, and the agent negotiates down to the intersection before it sends a single request.
Current version
UCP uses date-based versioning. The current release is 2026-08-25, which superseded 2026-04-08. Earlier releases: 2026-01-11, 2026-01-23.
Versions are not cosmetic. Moving from 2026-04-08 to 2026-08-25 changes where signing keys live, what a capability declaration must contain, and where every documentation URL points. A profile that mixes the two is internally inconsistent even when each half is valid on its own.
| 2026-04-08 | 2026-08-25 | |
|---|---|---|
| Signing keys field | signing_keys[] | keys[] (RFC 7517 JWK Set) |
Capability schema | Optional | Required in business profiles |
schema origin check | Origin match | Formal authority-binding algorithm |
spec URL origin | Bound to the namespace | https only – any host |
| Key types | EC P-256 | EC P-256 / P-384, OKP Ed25519 |
| Catalog docs path | /specification/catalog/… | /specification/shopping/catalog/… |
The three moving parts
1. Discovery
The business profile at /.well-known/ucp – served over HTTPS as application/json, publicly readable, cacheable. It carries ucp.version, a services registry of transport bindings, an optional capabilities registry, a payment_handlers registry, and a top-level keys[] array of public JWKs.
2. Negotiation
The agent intersects the business’s declared capabilities with its own, discards versions outside the declared constraints, and prunes orphaned extensions – an extension whose parent capability is not active is dropped. This is why advertising a capability you have not implemented is worse than advertising nothing: the agent will call it.
3. Transaction
The agent calls the endpoints the profile advertised, over one of four transports: rest (OpenAPI), mcp (OpenRPC), a2a (Agent Card) or embedded. Each transport binding is a separate entry in the same service array, and version identifies the service, not the transport.
Capability names are governed by domain ownership
Capabilities use reverse-domain names – dev.ucp.shopping.checkout, dev.ucp.common.identity_linking. The dev.ucp.* namespace is reserved for the governing body; a vendor extension must live under a namespace that vendor controls, such as com.example.payments.installments.
Since 2026-08-25 this is enforced by an algorithm rather than by convention: a platform derives the authority from the schema URL’s host and rejects any entity whose name does not match. See authority binding.
UCP is not ACP
ACP is OpenAI and Stripe’s protocol, and since March 2026 its role in ChatGPT is product discovery rather than in-chat checkout. UCP covers discovery and the transaction layer across Google’s surfaces. The technical groundwork overlaps heavily – complete product data, real availability, coherent prices – so the sequencing question is which to ship first, not which to pick.
Full comparison: ACP vs UCP for Magento 2. The payment authorization layer underneath both is covered in AP2.
What a Magento store has to do
| Layer | What it needs |
|---|---|
| Discovery | A schema-valid profile at /.well-known/ucp with correct headers and a published key |
| Catalog | Live /catalog/search, /catalog/lookup and /catalog/product endpoints |
| Cart & checkout | Endpoints for every capability the profile declares |
| Integrity | Response signing (RFC 9421) using the keys the profile publishes |
Magento has no native UCP support. angeo/module-ucp serves the profile; angeo/module-ucp-catalog serves the catalog endpoints it advertises. Both are MIT-licensed, target spec 2026-08-25, and the generated profile can be checked with bin/magento angeo:ucp:validate.
Questions
- What is the current UCP version?
- 2026-08-25. It replaced 2026-04-08 and changed the signing-key field from
signing_keys[]to the top-levelkeys[]JWK Set, madeschemarequired on business capabilities, and moved the documentation tree. - Is UCP free to implement?
- Yes. The specification is open source with no licence fee, and the reference schemas are public. The cost is engineering time on the endpoints your profile advertises.
- Can I publish a UCP profile without implementing any endpoints?
- Only in a narrow form. A profile with an empty
capabilitiesregistry is schema-valid but gives an agent nothing to call. Declaring a capability you have not implemented is the failure case, because negotiation activates it and the agent’s requests then fail. - Do I have to choose between UCP and ACP?
- No. They address different surfaces and their prerequisites overlap heavily. The practical sequence for most Magento merchants is to ship the ACP product feed first, then the UCP profile.
- What happens to my UCP profile when the spec version changes?
- A business may keep serving an older version. The spec supports this through
supported_versions, a map of older protocol versions to complete, self-contained profile URIs the business hosts itself.