# UCP Spec Breaking Changes: What Merchants Must Fix > The Universal Commerce Protocol's August release rewrites fulfillment, consent and signing keys. Four releases in, breaking changes are the pattern, and merchants track two rival specs. Canonical: https://brandonlazovic.dev/articles/ucp-breaking-schema-changes/ Author: Brandon Lazovic Published: 2026-09-16 ## The short version - The Universal Commerce Protocol's August 25, 2026 release makes backward-incompatible changes to fulfillment fields, buyer consent and signing keys, so an unmigrated integration fails against the new schema. - I diffed the two schemas directly. Buyer consent loses four named true-or-false fields, analytics, preferences, marketing and sale_of_data, and each is replaced by an object requiring three fields where a single true used to do. - Stripe co-developed the rival Agentic Commerce Protocol with OpenAI, then joined UCP's Tech Council on April 24, 2026, so a merchant is tracking two specifications on separate release schedules. - Agentic checkout is a maintained dependency with a release cadence, so budget for migration work every few months instead of treating the integration as finished. The Universal Commerce Protocol, the open standard that lets an AI agent browse a catalog and complete a purchase, shipped its fourth release on August 25, 2026. That release breaks three separate areas of the schema at once. If you integrated against the April version and have not looked since, your fulfillment payload, your consent payload and your signing keys are all now describing shapes the current specification no longer uses. > Four releases in eight months, each one a backward-incompatible step, is a release cadence rather than a settling-down period. ## What changed in the fourth Universal Commerce Protocol release? Three clusters of backward-incompatible change landed together, and the release notes name all three. Fulfillment fields were restructured, buyer consent was rebuilt on a different data model, and the way a party proves its identity was replaced outright. [1] The same release added support for grocery, which is the headline most coverage led with and the least consequential part for anyone already integrated. I read the published release history on September 8, 2026 to establish the sequence. The specification and its schemas are developed in the open, in a public repository with a companion schema validator, so any merchant can check a payload against the current shape without asking anyone. [3] Four releases exist: January 11, January 23, April 8, and August 25. [1] So the relevant comparison for most merchants is April against August, since anybody who integrated during the long spring gap is looking at every change below at once. ## Which Universal Commerce Protocol fields break? Fulfillment took the widest set of changes. Two configuration flags dropped an `allows_` prefix, so `allows_multi_destination` became `multi_destination` and `allows_method_combinations` became `method_combinations`. I confirmed both by diffing the schema files themselves. Those two are renames and the cheapest thing here to fix. Three changes underneath that are structural. The `fulfillment_option.description` field stopped being a plain string and became a structured object. The `multi_destination` field stopped being a map and became an array. And `fulfillment_available_method.type` widened from a fixed list of permitted values into an open string. [1] That last one deserves a second look, because it fails in the least helpful direction. When a field only accepts values from a fixed list, anything unexpected is rejected loudly at the boundary. Once it accepts any string, a typo or a stale value travels onward and surfaces later as an order that quietly does the wrong thing. Signing keys were the cleanest break. The `signing_keys[]` field was removed, and `keys[]`, holding a standard JSON Web Key Set, is now the only canonical way to publish the keys that prove a message came from you. [1] My own diff confirms it in both directions: the April schema carries `signing_keys` and no `keys`, and the August schema carries `keys` and no `signing_keys`. [3] A removed field is at least an honest failure, since nothing silently reinterprets it. One wrinkle worth knowing if you go looking. The profile schema also moved house between the two releases, from `source/discovery/profile_schema.json` to `source/schemas/profile.json`, so a naive file-by-file comparison reports it as a brand new schema rather than a changed one. ## Why does the consent change matter more than the others? Buyer consent moved from a fixed set of true-or-false fields to an open map keyed by reverse-DNS identifiers, meaning names like `dev.ucp.consent.marketing`. [1] That is a change in what consent can express, not a change in how it is spelled, and the two are not comparable amounts of work. I fetched both versions of `buyer_consent.json` from the specification's public repository and compared them directly. At the April release the consent object declares exactly four named properties: `analytics`, `preferences`, `marketing` and `sale_of_data`. [3] At the August release it declares none. In their place it accepts any key, and every value must be a `consent_purpose` object. Here is the part that decides how much work this is. That object requires three fields, `granted`, `source` and `description`, and optionally carries `links` and `segments`. [3] So a merchant who used to send `marketing: true` now sends a key naming the purpose, a `granted` flag, a `source` saying where the consent came from, and a `description` of what was agreed to. One boolean becomes an object with two mandatory fields that did not previously exist anywhere in your data. Under the old shape, the specification decided which things a shopper could agree to, and your job was to set each one correctly. Under the new shape, any party can define its own consent category, and the set is open-ended. Granular, per-segment preferences become possible, which is genuinely better for a shopper. The migration cost sits in a place teams underestimate. A rename can be handled by whoever owns the integration. A change in what consent means usually cannot, because consent records are the kind of thing privacy and legal review have already signed off on in their old shape. **Measured, from the schemas themselves:** two of the three required fields on the new consent object, `source` and `description`, are not derivable from a boolean. Nobody can migrate `marketing: true` without deciding what to write in them. **My inference from there:** the review cycle around those two fields will outlast the code change, so a team that schedules only the engineering work will be late. ## Why is Stripe on both standards at once? Stripe hedged, and the dates show the hedge clearly. The company co-developed the Agentic Commerce Protocol, the rival specification behind ChatGPT's shopping surfaces, with OpenAI. Then on April 24, 2026, Stripe joined the Universal Commerce Protocol's Tech Council, the technical body that steers that standard. [2] Coverage often blurs who was already there. Google, Shopify, Etsy, Target and Wayfair were the founding Tech Council members. [2] Stripe arrived later, in a group of five alongside Amazon, Meta, Microsoft and Salesforce, taking the council to ten. [2] So Stripe sits as a later arrival on the committee governing the competitor to the specification it helped write. From a payments company's position that is a sensible thing to do, since payment rails earn their money whichever protocol wins. The cost lands somewhere else. ## What does agentic checkout cost a merchant? Agentic checkout costs a merchant a second tracking obligation that nobody scoped when the project was approved. A merchant building for it in 2026 follows two specifications at once, on separate release schedules, neither of which has committed to a stable version, and both of which have a large payments company sitting inside them. Budget for that, or discover it during an outage. Four releases in eight months, three of them carrying breaking changes, is the observable evidence for treating this as ongoing maintenance. I wrote in [Merchant Center's eligible-but-not-distributed gap](/articles/merchant-center-eligible-not-distributed/) about the difference between passing a check and reaching a shopper. This is the same shape one layer down: an integration that passed its tests in April is not an integration that works in September, and nothing in your own systems will tell you that. ## What should you do before your next agent order? Read the release notes for the version you integrated against and every version published after it, in order, then repair the three areas the August release changed: fulfillment fields, buyer consent, and signing keys. Doing that now is a smaller job than it sounds. Doing it after an agent order fails in production is much larger, because the failure arrives as a broken purchase and never as a validation error you could have caught in staging. Three practical moves, in the order I would take them. Pin the specification version you are built against somewhere visible in your own repository, because a team that cannot state its current version cannot assess any release note. Put the consent change in front of whoever approved your consent model, and do that before the engineering work rather than after. And subscribe to the release feed, since these releases have arrived without a fixed schedule and the eight-month history gives no reason to expect one. ## Sources 1. Universal Commerce Protocol: releases — https://github.com/Universal-Commerce-Protocol/ucp/releases 2. Amazon, Meta, Microsoft, Salesforce, and Stripe Join the Universal Commerce Protocol Tech Council — https://www.newsfilecorp.com/release/294133/Amazon-Meta-Microsoft-Salesforce-and-Stripe-Join-the-Universal-Commerce-Protocol-Tech-Council 3. Universal Commerce Protocol: specification repository — https://github.com/universal-commerce-protocol/ucp