Google March 2026 UCP Update: Cart, Catalog, and Identity Linking Explained

Google Ships Three Core UCP Capabilities

Google's March 2026 UCP update is the most significant spec expansion since the protocol launched in January. Three capabilities went live simultaneously: Cart Management, Catalog Access, and Identity Linking. Each one fills a meaningful gap in the protocol. Together, they make Google Shopping a complete UCP integration target for agents that need end-to-end commerce coverage.

This post breaks down each capability technically: what endpoints are involved, what the JSON looks like, and how agents are expected to use them.

Cart Management

Before March 2026, UCP's checkout flow was sessionless in practice. An agent queried a product, got pricing, and submitted a purchase intent in a single round-trip. This worked for simple single-item purchases but fell apart for anything more complex: multi-item orders, quantity changes mid-session, or agents that need to show a cart to the consumer before committing.

Cart Management introduces persistent cart sessions with four core operations: create, update, delete, and item management.

Creating a Cart

POST /ucp/v1/carts
Authorization: Bearer <agent-token>
Content-Type: application/json

{
  "consumer_identity_token": "cit_01HXYZ...",
  "merchant_id": "google-shopping-merchant-48291",
  "currency": "USD"
}

The response returns a cart_id and an expires_at timestamp. Cart sessions are scoped to a consumer identity token and expire after 30 minutes of inactivity by default. Merchants can configure shorter windows.

Adding Items

POST /ucp/v1/carts/{cart_id}/items
Content-Type: application/json

{
  "product_id": "prod_8831920",
  "variant_id": "var_blue_xl",
  "quantity": 2,
  "unit_price": {
    "amount": "4299",
    "currency": "USD",
    "precision": 2
  }
}

The unit_price field is included in the request, and the server validates it against current pricing. If the price has changed since the agent fetched the catalog, the server returns a price_mismatch error with the current price. This closes a race condition that existed in the old sessionless flow, where an agent could submit a purchase at a stale price.

Removing Items and Updating Quantities

Items can be removed with DELETE /ucp/v1/carts/{cart_id}/items/{item_id}. Quantities are updated with a PATCH to the same endpoint, passing the new quantity field. The server recalculates totals and returns the updated cart state on every mutation.

Why This Matters

Cart sessions give agents a staging area. An agent can now assemble a multi-item order, present the full cart summary to the consumer for review, and only then trigger the final purchase confirmation. Before this capability, agents had to either submit single-item purchases or implement their own cart state management client-side, which created consistency problems if prices or availability changed between the agent's state and the merchant's.

The UCP conformance test suite has a dedicated cart-management test group that covers concurrent modification conflicts, item removal edge cases, and cart expiry behavior. Any agent targeting Google Shopping should run these tests before shipping.

Catalog Access

Google's Catalog Access capability provides a structured product feed endpoint with filtering, faceting, and cursor-based pagination. This is not Google Shopping's existing Search API. It is a purpose-built UCP endpoint designed for agent consumption, with a schema defined by the UCP specification rather than Google's legacy APIs.

The Discovery Endpoint

Merchants advertise their catalog endpoint through the /.well-known/ucp manifest:

{
  "ucp_version": "1.2",
  "endpoints": {
    "catalog": "/ucp/v1/catalog",
    "cart": "/ucp/v1/carts",
    "checkout": "/ucp/v1/checkout",
    "identity": "/ucp/v1/identity"
  },
  "capabilities": ["cart_management", "catalog_access", "identity_linking"]
}

The capabilities array tells agents which March 2026 features are supported before making any capability-specific calls. Agents should check this manifest before attempting Cart Management or Identity Linking requests.

Querying the Catalog

GET /ucp/v1/catalog?q=running+shoes&size=10.5&max_price=12000&in_stock=true&cursor=eyJwYWdlIjo...
Authorization: Bearer <agent-token>

Prices in catalog responses are always expressed as integers in the smallest currency unit (cents for USD, pence for GBP), with a precision field indicating decimal placement. This avoids floating-point issues that caused rounding bugs in early implementations.

A typical product result looks like this:

{
  "product_id": "prod_7729104",
  "title": "Brooks Ghost 16 Running Shoe",
  "brand": "Brooks",
  "variants": [
    {
      "variant_id": "var_ghost16_m_105_blk",
      "size": "10.5",
      "color": "Black",
      "price": { "amount": "11999", "currency": "USD", "precision": 2 },
      "inventory_status": "in_stock",
      "ships_by": "2026-03-24"
    }
  ],
  "return_policy": { "window_days": 30, "type": "free" },
  "ucp_checkout_eligible": true
}

The ucp_checkout_eligible flag is worth noting. Not every product in a Google Shopping catalog can be transacted through UCP. Products from merchants who have not completed UCP conformance certification are marked false here, so agents know not to attempt a checkout session on them.

Pagination

Catalog responses include a next_cursor field for cursor-based pagination. Offset-based pagination (page=2) is not supported. This is a deliberate design choice: catalogs can change between requests, and cursor-based pagination produces consistent results even when new items are added or removed mid-traversal.

Identity Linking

Identity Linking is the most architecturally significant capability in the March update. It defines how agents obtain authorization to act on behalf of a specific consumer with a specific merchant, using an OAuth 2.0-style flow adapted for agent contexts.

The Authorization Flow

The flow has three steps. First, the agent requests an authorization URL from the merchant's identity endpoint:

POST /ucp/v1/identity/authorize
Content-Type: application/json

{
  "agent_id": "agent_shopbot_v2",
  "requested_scopes": ["cart:write", "checkout:initiate", "orders:read"],
  "redirect_uri": "https://myagent.example.com/ucp/callback",
  "consumer_hint": "user@example.com"
}

The merchant returns an authorization_url that the agent presents to the consumer for approval. The consumer authenticates with the merchant (using their existing account) and approves the requested scopes.

After approval, the merchant redirects to the redirect_uri with an authorization code. The agent exchanges this code for a scoped Consumer Identity Token (CIT):

POST /ucp/v1/identity/token
Content-Type: application/json

{
  "grant_type": "authorization_code",
  "code": "auth_code_abc123",
  "agent_id": "agent_shopbot_v2",
  "redirect_uri": "https://myagent.example.com/ucp/callback"
}

The response includes the CIT, its expiry, the granted scopes, and a refresh token. CITs are short-lived: the default expiry in the Google implementation is 4 hours. Agents must handle token refresh gracefully.

Scope Design

Scopes are granular by design. An agent granted cart:write and checkout:initiate can build and submit carts but cannot read past orders. An agent granted only orders:read can check delivery status but cannot initiate any purchases. This lets consumers grant limited trust to agents without handing over full account access.

The ucp.dev specification defines the canonical scope list. Merchants can add custom scopes but cannot remove standard ones.

What Developers Need to Know

Identity Linking means agents no longer need to ask consumers for merchant passwords or email addresses to act on their behalf. The consumer approves once per merchant, and the agent operates within those scopes until the token expires or is revoked. Revocation is immediate: the consumer can revoke agent access from their merchant account at any time, and subsequent CIT usage returns a 401 identity_revoked error.

For developers building agents that work across multiple merchants, the identity token management overhead is real. Each merchant-consumer pair requires a separate authorization flow and separate token lifecycle. Some agent frameworks are starting to handle this automatically, but if you are building from scratch, build your token store and refresh logic before you build anything else.

The Bigger Picture

The March 2026 update brings Google Shopping's UCP implementation to parity with Shopify's. Both now support the full capability set described in the ucp.dev specification. For agent developers, this means you can write a single integration against the UCP spec and reach both platforms without platform-specific workarounds.

For merchants on Google Shopping, these capabilities are available through the standard merchant UCP enrollment process. Conformance certification for Cart Management and Catalog Access is required before the ucp_checkout_eligible flag is set to true on your products.

We have updated the UCPList directory listing for Google Shopping to reflect all three new capabilities. If you are tracking which platforms support which UCP features, the directory is kept current as implementations ship.