Check register

Every requirement the suite checks, cited to the spec

The spck.dev conformance suite is built from a requirements register scraped from the UCP specification and quote-verified against SHA-pinned sources. This page lists the 346 requirements the suite currently covers; each links to the requirement text and its exact spec citation. For the full picture including requirements not yet covered, see the coverage matrix; for how verdicts are graded, the rubric.

Cart 12

CART-001On cart-to-checkout conversion, business MUST use cart contents and MUST ignore overlapping fields in the checkout payload
CART-002If an incomplete checkout already exists for the given cart_id, business MUST return the existing checkout session rather than creating a ne…
CART-017For Update Cart (full replacement), the platform MUST send the entire cart resource
CART-018On Cancel Cart, business MUST return the cart state before deletion
CART-022All cart REST request and response bodies MUST be valid JSON as specified in RFC 8259
CART-023All cart REST endpoints MUST be served over HTTPS with minimum TLS version 1.3
CART-026When an Idempotency-Key is provided, the server MUST store the key with the operation result for at least 24 hours, return the cached result…
CART-029A cart response object MUST include ucp, id, line_items, currency, and totals
CART-030cart_id is only available on create_checkout (create:optional) and MUST be omitted on update
CART-031Each cart line item MUST include id, item, quantity, and totals
CART-032Line item quantity MUST be an integer of at least 1
CART-033Each line item's item MUST include id, title, and price

Catalog 27

CAT-001Pagination response MUST include has_next_page
CAT-002When has_next_page is true, cursor MUST be present (if/then schema constraint)
CAT-003Cursor to fetch next page MUST be present when has_next_page is true
CAT-005limit request parameter has minimum 1 and default 10
CAT-009A valid search request MUST include at least one of: a query string, one or more filters, or an extension-defined input
CAT-010Implementations MUST validate that incoming requests contain at least one recognized input
CAT-012Empty search returns products:[] with no messages (not an error)
CAT-013Lookup MUST support lookup by product ID and variant ID
CAT-014get_product MUST support product ID and variant ID for the single id parameter
CAT-015Duplicate identifiers in the request MUST be deduplicated
CAT-016When multiple identifiers resolve to the same product, it MUST be returned once
CAT-017Variants without an inputs entry MUST NOT appear in lookup responses
CAT-018lookup response variants MUST include a non-empty inputs array (correlation metadata)
CAT-019For get_product / catalog/product, an unknown identifier (NOT_FOUND) returns HTTP 200 with ucp.status:"error" and a descriptive message
CAT-020All application-level outcomes (incl. not-found) return HTTP 200 with the UCP envelope and optional messages array
CAT-022When the Lookup capability is advertised, both /catalog/lookup and /catalog/product MUST be available
CAT-023REST transport MUST implement endpoints for each advertised catalog capability per its requirements
CAT-024REST transport MUST support cursor-based pagination with default limit of 10
CAT-025REST transport MUST return HTTP 200 for lookup requests; unknown identifiers result in fewer products returned
CAT-026REST transport MUST return HTTP 400 with request_too_large error for requests exceeding batch size limits
CAT-027Lookup implementations MAY enforce a maximum batch size and MUST reject requests exceeding their limit with an appropriate error
CAT-028Lookup ids array is required with minItems 1
CAT-029search_response MUST include ucp and products
CAT-030lookup_response MUST include ucp and products
CAT-031get_product_response MUST include ucp and a singular product object
CAT-032For Variant ID lookups via get_product, the requested variant MUST be the first element (featured)
CAT-033get_product response MUST include product.selected when the product has configurable options

Fulfillment 7

FUL-003A fulfillment_method MUST include id, type, and line_item_ids
FUL-004fulfillment_method.type MUST be one of shipping or pickup
FUL-007A fulfillment_group MUST include id and line_item_ids
FUL-008A fulfillment_option MUST include id, title, and totals
FUL-009options[].title is the required primary label that distinguishes the option from its siblings
FUL-026When supports_multi_group is false (default), the business MUST consolidate all items into a single group per method
FUL-030A shipping_destination MUST include an id (it is a postal_address plus a required id)

Identity linking 35

IDL-001Identity linking uses OAuth 2.0 as the v1 auth mechanism.
IDL-015Businesses MUST implement OAuth 2.0.
IDL-016Businesses MUST publish authorization server metadata via RFC 8414 at /.well-known/oauth-authorization-server.
IDL-017Businesses MUST populate scopes_supported in RFC 8414 metadata so platforms can detect scope mismatches before initiating an authorization f…
IDL-018Businesses MUST return the iss parameter in the authorization response.
IDL-019Businesses MUST enforce PKCE validation at the token endpoint for all authorization code exchanges; requests without a valid code_verifier M…
IDL-020Businesses MUST enforce exact string matching for the redirect_uri parameter during authorization requests; the token-request redirect_uri M…
IDL-021For loopback redirect URIs (127.0.0.1 or [::1]) businesses MUST ignore the port component and match on scheme, host, and path only.
IDL-022Businesses MUST declare supported client authentication methods in token_endpoint_auth_methods_supported and enforce one of the declared met…
IDL-023When 'none' is advertised, businesses MUST require PKCE with S256 and MUST reject any authorization code redemption lacking a valid code_ver…
IDL-024Requests that fail the negotiated authentication method MUST be rejected with invalid_client; requests that fail PKCE MUST be rejected with …
IDL-025Businesses MUST validate user identity tokens on every user-authenticated request (iss, aud, exp, scopes, and client_id/azp).
IDL-026Businesses MUST emit a WWW-Authenticate: Bearer challenge on 401 Unauthorized (identity_required) and 403 Forbidden (insufficient_scope) res…
IDL-027Businesses MUST implement token revocation; revoking a refresh_token MUST also immediately invalidate all access_tokens issued from it.
IDL-028Businesses MUST support revocation requests authenticated with the same client credentials used at the token endpoint.
IDL-029Businesses MUST support standard UCP scopes as defined in the Scopes section.
IDL-033The issuer value in discovered metadata MUST match the discovery base URI exactly; platforms MUST NOT normalize before comparison (byte-for-…
IDL-036The token-request code_verifier MUST correspond to the code_challenge sent in the authorization request; businesses MUST reject token reques…
IDL-037Scope names MUST match the pattern ^[a-z][a-z0-9_]*$.
IDL-040On identity_required the business MUST return 401 Unauthorized, a WWW-Authenticate: Bearer challenge, and a UCP error body with code 'identi…
IDL-041The identity_required WWW-Authenticate header MUST include a realm parameter set to the business's issuer URI from RFC 8414 metadata.
IDL-042When the request included a token that was invalid/expired/unverifiable, the identity_required header MUST also include error="invalid_token…
IDL-044continue_url MUST NOT be used to convey a pre-baked OAuth authorization request; the platform constructs its own authorization request.
IDL-045On insufficient_scope the business MUST return 403 Forbidden, a WWW-Authenticate: Bearer challenge, and a UCP error body with code 'insuffic…
IDL-046The insufficient_scope WWW-Authenticate header MUST include realm, error="insufficient_scope", and scope="<space-separated full required sco…
IDL-047The insufficient_scope scope parameter MUST list the full set of scopes required for the operation, not just the missing ones.
IDL-049Plain PKCE (plain) MUST NOT be used; PKCE S256 is REQUIRED for all authorization code flows, and businesses MUST reject exchanges without a …
IDL-050Public clients cannot keep a client_secret confidential and MUST use 'none'; businesses MUST NOT require client_secret_basic as the only met…
IDL-052The realm parameter MUST match the business's issuer URI so platforms can correlate the challenge with the correct authorization server.
IDL-053All communication between platform and business MUST use HTTPS with a minimum of TLS 1.2.
IDL-055Platforms MUST revoke user identity tokens at the business's revocation endpoint when a user unlinks; businesses MUST reject subsequent requ…
IDL-058authorization_response_iss_parameter_supported and code_challenge_methods_supported:["S256"] MUST both be present in UCP-compliant RFC 8414 …
IDL-059config.scopes property names MUST conform to the scope_token pattern {capability}:{scope}.
IDL-060Business identity_linking config object is required and MUST contain a 'scopes' property.
IDL-061The `issuer` value in RFC 8414 metadata and the `iss` parameter returned in authorization responses MUST be identical byte-for-byte; platfor…

Order 26

ORD-001Get Order MUST return the full order entity as a current-state snapshot (complete record of what was purchased, how it will be delivered, an…
ORD-002The order entity MUST include the required top-level fields ucp, id, checkout_id, permalink_url, line_items, fulfillment, and totals
ORD-003currency MUST NOT be treated as a required top-level order field in spec version 2026-01-23 (currency is absent from order.json required[])
ORD-004Each order line item MUST include id, item, quantity, totals, and status
ORD-005Line item quantity MUST include both total and fulfilled counts
ORD-006Line items reflect what was purchased at checkout and MUST be retained as the immutable source of truth for what was ordered
ORD-007Adjustments are an append-only log; each adjustment MUST include id, type, occurred_at, and status
ORD-008Each adjustment requires id, type, occurred_at, and status
ORD-009Each fulfillment event (append-only log of actual shipments) MUST include id, occurred_at, type, and line_items
ORD-010Each fulfillment expectation (buyer-facing grouping) MUST include id, line_items, method_type, and destination
ORD-012Businesses POST order lifecycle events to the platform-provided webhook URL, sending the full order entity (not incremental deltas)
ORD-013Businesses MUST send an 'Order created' event with a fully populated order entity
ORD-014Webhook payloads MUST be signed by the business and verified by the platform to ensure authenticity and integrity
ORD-015Businesses MUST sign all webhook payloads using a key from their signing_keys array (published in /.well-known/ucp), and the signature MUST …
ORD-016Businesses MUST retry failed webhook deliveries
ORD-018Each expectation requires id, line_items, method_type, and destination
ORD-019Each fulfillment event requires id, occurred_at, type, and line_items
ORD-020Order confirmation requires id and permalink_url
ORD-021All REST response bodies MUST be valid JSON (RFC 8259)
ORD-022All REST endpoints MUST be served over HTTPS with minimum TLS version 1.3
ORD-026Webhook payloads MUST be signed by the business and verified by the platform
ORD-027Businesses MUST sign all webhook payloads per Message Signatures using RFC 9421 headers (Signature, Signature-Input, Content-Digest)
ORD-028Businesses MUST include the UCP-Agent header with profile URL for signer identification on webhooks
ORD-029Businesses MUST send the 'Order created' event with a fully populated order entity
ORD-030Businesses MUST send the full order entity on updates (not incremental deltas)
ORD-031Businesses MUST retry failed webhook deliveries

Payment 38

PAY-001A business/platform/response profile advertises payment handlers in the payment_handlers registry, keyed by reverse-domain name
PAY-002A payment handler base/declaration must include an id field identifying the handler instance.
PAY-003A platform-schema payment handler declaration must include spec and schema fields.
PAY-004A platform-schema payment handler declaration MUST additionally include spec and schema URLs
PAY-005When a handler declares available_instruments, the array MUST contain at least one instrument type (minItems 1)
PAY-007An available_payment_instrument MUST include a type (instrument type identifier)
PAY-008A payment instrument must include id, handler_id, and type, where handler_id corresponds to the id of the payment handler definition.
PAY-009Credentials flow Platform to Business only; businesses must not echo credentials back in responses (unidirectional flow).
PAY-010The handler_id in the payload ensures the business knows which payment credential provider key to use, preventing key confusion attacks (Han…
PAY-011Credentials flow Platform -> Business only; businesses MUST NOT echo credentials back in responses
PAY-012Businesses must filter the handlers list based on the context of the cart (dynamic filtering).
PAY-014Businesses MUST validate handler_id before processing (ensure handler is in the advertised set)
PAY-015A card credential must include type (const 'card') and card_number_type.
PAY-016A token credential must include type and token.
PAY-017A binding must include checkout_id identifying the checkout session the token is bound to (prevents token reuse across checkouts/participant…
PAY-018continue_url MUST be provided when checkout status is requires_escalation
PAY-019Businesses must embed a cryptographic signature (merchant_authorization) in checkout responses when AP2 is negotiated.
PAY-020A payment credential MUST include a type discriminator
PAY-021When ap2_mandate is negotiated, the business must include ap2.merchant_authorization in all relevant checkout responses.
PAY-023A card payment instrument MUST have type const 'card'
PAY-024A token credential MUST include type and token
PAY-026All AP2 signatures must use one of the approved algorithms (ES256/ES384/ES512).
PAY-027Businesses must embed their signature in the checkout response body under ap2.merchant_authorization.
PAY-029Completion of an autonomous AP2 flow must produce two distinct mandate artifacts: a checkout_mandate and a payment_mandate.
PAY-031When AP2 is active, the business must embed a cryptographic signature in checkout responses proving the terms are authentic.
PAY-034When AP2 is negotiated, the business must include ap2.merchant_authorization in all checkout responses.
PAY-035The merchant_authorization is a JWS Detached Content signature; its header must contain alg (ES256/ES384/ES512) and kid claims.
PAY-036On AP2 complete requests the checkout_mandate (and ap2 object) is required.
PAY-037A public signing key must be available for the business to verify the mandate's signature.
PAY-038If a public key cannot be resolved or the signature is invalid, the business must return an error.
PAY-039Businesses must embed their signature in the checkout response body under ap2.merchant_authorization using JWS detached content.
PAY-040The business's signature must cover both the JWS header and the checkout payload (preventing alg-substitution attacks).
PAY-041The platform must produce two distinct mandate artifacts (checkout_mandate and payment_mandate).
PAY-042The checkout mandate must contain the full checkout response including the ap2.merchant_authorization field.
PAY-043All JSON payloads must be canonicalized using JSON Canonicalization Scheme (JCS) per RFC 8785.
PAY-044Once AP2 is negotiated, both parties must follow the defined mandate flow steps to ensure cryptographic integrity.
PAY-045A completion request without mandates must result in a session failure.
PAY-047Upon receiving the complete request, the business must perform the defined negotiation-enforcement and mandate/authorization verification st…

Signatures 31

SIG-001UCP signs and verifies HTTP messages using RFC 9421 HTTP Message Signatures across all HTTP-based transports.
SIG-002All implementations MUST support verifying P-256 (ES256) signatures.
SIG-006The algorithm is derived from the key's crv field in the JWK; alg is NOT included in Signature-Input parameters.
SIG-007Public keys MUST be represented using JSON Web Key (JWK) format as defined in RFC 7517.
SIG-008Public keys are published in the signing_keys array of the party's UCP profile at /.well-known/ucp.
SIG-009During key rotation, continue accepting signatures from old keys for a grace period of minimum 7 days.
SIG-010Content-Digest follows RFC 9530 and hashes the raw body bytes; implementations MUST use sha-256.
SIG-012Content-Digest header is required when a request/response has a body.
SIG-013Signature-Input and Signature headers are required on requests and responses.
SIG-014REST request signed components MUST include @method, @authority, and @path (all Required).
SIG-015REST request signed components MUST include content-digest and content-type when the request has a body.
SIG-016idempotency-key MUST be a signed component for POST, PUT, DELETE, PATCH requests.
SIG-017@query MUST be a signed component if the request has query parameters.
SIG-018ucp-agent MUST be a signed component if the UCP-Agent header is present.
SIG-019ECDSA signatures MUST use fixed-width raw r||s encoding per RFC 9421, not ASN.1/DER (64 bytes P-256, 96 bytes P-384).
SIG-020REST response signed components use @status instead of @method (Required).
SIG-021REST response signed components MUST include content-digest and content-type if the response has a body.
SIG-023Server storage of idempotency keys must be a minimum of 24 hours, recommended 48 hours.
SIG-024On idempotency storage failure, fail closed (reject request with 503).
SIG-025On duplicate idempotency key, return cached response and do not re-execute.
SIG-027Webhook notifications MUST be signed.
SIG-031signature_missing maps to HTTP 401 (required signature header/field not present).
SIG-032signature_invalid maps to HTTP 401 (signature verification failed).
SIG-033key_not_found maps to HTTP 401 (key ID not found in signer's signing_keys).
SIG-034digest_mismatch maps to HTTP 400 (body digest doesn't match Content-Digest header).
SIG-035algorithm_unsupported maps to HTTP 400 (signature algorithm not supported).
SIG-036Verification must reconstruct the signature base and reject with signature_invalid if ECDSA verification fails.
SIG-037Verification must return key_not_found when the kid is not present in the signer's signing_keys.
SIG-038Verification must return digest_mismatch when Content-Digest does not match the recomputed sha-256 of the body bytes.
SIG-040The `profile` value in the `UCP-Agent` header MUST be a quoted string containing an HTTPS URL (non-HTTPS URLs must be rejected).
SIG-041For business profiles, the `UCP-Agent` profile URL MUST point to `/.well-known/ucp`; platform profile URLs are not path-constrained.

Totals 9

TOT-004Unknown (non-well-known) totals types MUST include display_text
TOT-005Exactly one totals entry of type subtotal MUST be present
TOT-006Exactly one totals entry of type total MUST be present
TOT-014Subtractive well-known types (discount, items_discount) MUST have negative amounts
TOT-015Additive well-known types (subtotal, fulfillment, tax, fee) MUST have non-negative amounts
TOT-017Sum of a parent entry lines[] amounts MUST equal the parent entry amount
TOT-019Each sub-line entry requires both display_text and amount
TOT-020Each top-level totals entry requires both type and amount
TOT-021Price requires a non-negative integer amount and an ISO 4217 currency code

Transports 6

A2A-001The A2A business agent MUST return the checkout object inside an A2A Message DataPart keyed `a2a.ucp.checkout`
MCP-001When the catalog Lookup capability is advertised, the MCP endpoint MUST expose both `lookup_catalog` and `get_product` tools
MCP-003A conforming MCP checkout endpoint MUST implement JSON-RPC 2.0, provide all core checkout tools, return errors per core spec, return busines…
MCP-004MCP transport MUST expose UCP OpenRPC operations via JSON-RPC tools/call, mapping method->params.name and params->params.arguments
MCP-005A business implementing the MCP order binding MUST implement the `get_order` tool per the OpenRPC schema
MCP-006A conforming catalog MCP transport implementation MUST implement JSON-RPC 2.0 correctly, validate tool inputs against UCP schemas, support c…

Checkout-Lifecycle 39

CHK-001Create Checkout initiates a new checkout session via POST /checkout-sessions
CHK-002Get Checkout retrieves current state via GET /checkout-sessions/{id}
CHK-003Update Checkout updates a session via PUT /checkout-sessions/{id}
CHK-004Complete Checkout places the order via POST /checkout-sessions/{id}/complete
CHK-005Cancel Checkout cancels a session via POST /checkout-sessions/{id}/cancel
CHK-006Update Checkout performs a full replacement of the checkout resource; the platform is REQUIRED to send the entire checkout resource
CHK-007Each PUT replaces the entire session, so clients must include all previously set fields they wish to retain
CHK-008Complete Checkout response is the checkout object with the order field populated (order provides id and permalink_url)
CHK-012After a checkout session reaches the state completed it is considered immutable
CHK-013Status field enum is constrained to the six lifecycle values
CHK-014Checkout response MUST include required top-level fields: ucp, id, line_items, status, currency, totals, links
CHK-015Business MUST include at least one message with severity requires_buyer_input or requires_buyer_review when returning status = requires_esca…
CHK-016Top-level checkout id is omitted on create and complete requests and required on update requests (ucp_request)
CHK-017ucp envelope field is omitted on request bodies (ucp_request: omit)
CHK-018line_items is required on create and update requests and omitted on complete requests
CHK-019currency is omitted on create, update, and complete requests (merchant-determined, response-only)
CHK-020status, totals, messages, links, expires_at, continue_url, and order are response-only (ucp_request: omit) and omitted on requests
CHK-021payment is optional on create and update, and required on complete requests
CHK-022Cancel Checkout cancels a session via POST /checkout-sessions/{id}/cancel
CHK-025Businesses MUST provide continue_url when returning status = requires_escalation (Availability)
CHK-028continue_url MUST be an absolute HTTPS URL
CHK-033status field enum is constrained to the six lifecycle values
CHK-034Checkout response MUST include required top-level fields: ucp, id, line_items, status, currency, totals, links
CHK-035Top-level checkout id is omitted on request bodies (ucp_request: omit)
CHK-037Logic handling the checkout sessions MUST be deterministic
CHK-038Business MUST provide continue_url when returning status = requires_escalation (Business guideline restatement)
CHK-039payment is optional on create and update, and required on complete requests
CHK-043continue_url MUST be provided when status is requires_escalation (schema field description)
CHK-044All REST request and response bodies MUST be valid JSON per RFC 8259
CHK-045All REST endpoints MUST be served over HTTPS with minimum TLS version 1.3
CHK-048When an Idempotency-Key is provided, server MUST store the key+result >=24h, return cached result for duplicates, and return 409 if reused w…
CHK-050All REST request and response bodies MUST be valid JSON per RFC 8259
CHK-051All REST endpoints MUST be served over HTTPS with minimum TLS version 1.3
CHK-053On create with all items unavailable, response carries ucp.status:error with messages and no resource body
CHK-056Businesses MUST NOT complete a transaction with unresolved eligibility claims; accepted claims MUST be resolved before completion
IDM-002When an Idempotency-Key is provided, the server MUST store the key with the operation result for at least 24 hours
IDM-003When an Idempotency-Key is provided, the server MUST return the cached result for duplicate keys
IDM-004When an Idempotency-Key is provided, the server MUST return 409 Conflict if the key is reused with different parameters
IDM-005409 Conflict indicates the request could not be completed due to a conflict (e.g., idempotent key reuse)

Discount-Consent-Identity 27

DSC-001Submitting discounts.codes replaces any previously submitted codes (replacement semantics).
DSC-002Sending an empty codes array clears all discount codes.
DSC-003Discount codes are matched case-insensitively by the business.
DSC-004discounts.applied contains all active discounts (code-based and automatic) in the response.
DSC-005When multiple valid discount codes are submitted, all are applied (accept-both) and appear in discounts.applied.
DSC-006When a submitted discount code cannot be applied, the business communicates this via the messages[] array.
DSC-007A rejected discount code still appears in discounts.codes (echoed back) but not in discounts.applied.
DSC-010Automatic discounts appear in discounts.applied with automatic: true and no code field; they are applied without platform action and cannot …
DSC-011A fixed-amount discount code decreases the total correctly and surfaces applied discount details (code and amount).
DSC-012An applied_discount must include title and amount; amount is a non-negative integer in minor currency units.
DSC-013applied_discount.method, when present, must be one of 'each' or 'across'.
DSC-014An allocation must include path and amount; allocation amount is a non-negative integer in minor currency units.
DSC-015The discounts object is optional on create and update operations and must be omitted on complete.
DSC-016The sum of allocations[].amount must equal the applied_discount.amount.
DSC-017All discount amounts are positive integers in minor currency units; when presenting totals, discount types are displayed as subtractive.
DSC-018totals[type=items_discount].amount must equal sum(line_items[].discount).
DSC-019Buyer consent is communicated as boolean states within the buyer.consent object (analytics, preferences, marketing, sale_of_data) on create_…
DSC-020Each buyer consent state (analytics, preferences, marketing, sale_of_data), when present, must be a boolean.
DSC-021The buyer consent object is optional on create and update operations and must be omitted on complete (consent is not required to gate comple…
IDL-005Businesses must implement OAuth 2.0 (RFC 6749).
IDL-006Businesses must adhere to RFC 8414 to declare the location of their OAuth 2.0 endpoints at /.well-known/oauth-authorization-server.
IDL-007Businesses must enforce Client Authentication at the Token Endpoint.
IDL-009Businesses must support standard UCP scopes, granting tokens permission to all associated Operations for a given resource.
IDL-010Businesses must implement standard Token Revocation as defined in RFC 7009.
IDL-011Businesses must revoke the specified token and should recursively revoke all associated tokens (revoking a refresh_token must also immediate…
IDL-012Businesses must support revocation requests authenticated with the same client credentials used for the token endpoint.
IDL-013A scope covering a capability must grant access to all operations associated with that capability (e.g., ucp:scopes:checkout_session must gr…

Discounts-Consent 14

DSC-008Discount amounts are reflected in totals[] and line_items[].totals[]
DSC-009When a cart is converted to a checkout via cart_id, businesses MUST carry forward any discount codes that were applied to the cart
DSC-022Invariant: sum of allocations[].amount equals applied_discount.amount
DSC-023applied_discount MUST include title and amount
DSC-024applied_discount.method MUST be one of 'each' or 'across' when present
DSC-025applied_discount.priority MUST be an integer >= 1 (lower applied first)
DSC-026allocation MUST include path and amount
DSC-027discounts.applied is response-only and MUST be omitted from requests
DSC-028On checkout complete, the discounts object MUST be omitted from the request
DSC-029Multiple valid discount codes are both applied (accept-both)
DSC-030When multiple codes are submitted and one is invalid, only the valid discount is applied (accept-one-reject-one); rejected appears in messag…
DSC-032When the consent extension is supported, the buyer object in checkout is extended with a consent field containing boolean consent states
DSC-033consent properties (analytics, preferences, marketing, sale_of_data) MUST be booleans when present
DSC-034On checkout complete, the buyer object (carrying consent) MUST be omitted from the request

Discovery-And-Profile 2

DISC-004Implementations MUST reject profile URLs not served over HTTPS.
DISC-005service endpoint MUST be a valid HTTPS URL.

Discovery-Negotiation 18

DISC-001All capability and service names MUST use the format {reverse-domain}.{service}.{capability}
DISC-002The spec and schema fields are REQUIRED for all capabilities
DISC-003The origin of capability spec/schema URLs MUST match the namespace authority
DISC-007A service endpoint MUST be a valid URL with scheme (https)
DISC-013Discovery profile at /.well-known/ucp MUST return 200 OK with the expected version, capabilities, and payment handlers
DISC-014All spec and schema URLs advertised in the discovery profile MUST be valid and resolvable (return 200 with valid HTML/JSON)
NEG-010Businesses MUST compute the intersection of platform and business capabilities
NEG-011Extensions without their parent capability in the intersection MUST be excluded
NEG-012Businesses MUST include the ucp field in every response containing version and active capabilities
NEG-013If negotiation fails, businesses MUST return an error response
NEG-014Businesses MUST validate the platform's version and determine compatibility
NEG-015If platform version <= business version, the business MUST process the request
NEG-016If platform version > business version, the business MUST return version_unsupported error
NEG-017Businesses MUST include the version used for processing in every response
NEG-018All UCP communication MUST occur over HTTPS
NEG-019REST requests and responses MUST use Content-Type application/json
NEG-020REST implementations MUST use standard HTTP verbs (e.g., POST for creation, GET for retrieval)
NEG-021REST implementations MUST use standard HTTP status codes (e.g., 200, 201, 400, 401, 500)

Error-Envelope 8

ERR-009Warning message MUST include type, code, and content fields.
ERR-010Warning message type discriminator MUST be the constant "warning".
ERR-025Info message MUST include type and content fields.
ERR-026Info message type discriminator MUST be the constant "info".
ERR-028Error response MUST include ucp and messages.
ERR-029Error response ucp.status MUST be 'error'.
ERR-030Error response messages array MUST contain at least one message (minItems 1).
ERR-031A Message MUST be exactly one of error, warning, or info (oneOf discriminated container).

Errors-Validation-Security 20

ERR-001An error message MUST include the fields type, code, content, and severity (all four are required on a Message Error).
ERR-002The error message type discriminator MUST be the constant string "error".
ERR-003The error code field MUST be a string; defined values include missing, invalid, out_of_stock, payment_declined, requires_sign_in, requires_3…
ERR-004The error severity field MUST be one of exactly three enum values: recoverable, requires_buyer_input, requires_buyer_review.
ERR-005Errors with requires_* severity contribute to status requires_escalation.
ERR-006REST implementations MUST use standard HTTP status codes (e.g., 200, 201, 400, 401, 500) for responses including errors.
ERR-007If negotiation fails, businesses MUST return an error response (status requires_escalation with a type:error message, e.g. version_unsupport…
SEC-001A request to the simulation endpoint without the Simulation-Secret header MUST be rejected with 403 Forbidden.
SEC-002A request to the simulation endpoint with an incorrect Simulation-Secret MUST be rejected with 403 Forbidden.
SEC-003A request to the simulation endpoint with the correct Simulation-Secret MUST be accepted with 200 OK.
SEC-004All UCP communication MUST occur over HTTPS.
VAL-001When an out-of-stock item is added to a checkout session, the server MUST return a 400 Bad Request error indicating insufficient stock.
VAL-002An inventory/quantity validation failure on checkout creation MUST return a 400 Bad Request error.
VAL-003A request referencing a non-existent product MUST return a 400 Bad Request error indicating the product was not found.
VAL-004Submitting a payment instrument with a known failing token at checkout completion MUST return a 402 Payment Required error.
VAL-005Attempting to complete a checkout without required fulfillment MUST return a 400 Bad Request error.
VAL-006Error responses MUST be structured: a 400 error body MUST contain a populated 'detail' field describing the error.
VAL-007An update specifying an invalid adjustment status (non-conforming literal) MUST be rejected with a 422 Unprocessable Entity error due to val…
VAL-008An update with a malformed adjustments field (e.g., a dict instead of a list) MUST return a 422 Unprocessable Entity error.
VAL-009A request using an unknown discount code MUST succeed with 200 OK, with no discount applied (graceful handling, not an error).

Overview 9

OVR-001All capability and service names advertised in a profile MUST use the reverse-domain format {reverse-domain}.{service}.{capability}
OVR-003The origin of each capability's spec/schema URL MUST match the namespace authority derived from its reverse-domain name
OVR-004Businesses MUST include the ucp field in every response, containing the processing version and the array of active capabilities
OVR-005In ucp.capabilities the business MUST include only capabilities that are (1) in the negotiated intersection and (2) relevant to this respons…
OVR-006Verifiers MUST ensure the authenticated identity is consistent with the UCP-Agent profile, and (for API key/OAuth/mTLS) MUST confirm the aut…
OVR-008REST requests and responses MUST use Content-Type application/json
OVR-009A version-specific (leaf) profile served from a supported_versions URI MUST NOT contain a supported_versions field
OVR-010The protocol version MUST be a dated YYYY-MM-DD release; businesses MUST NOT advertise a non-date version string (e.g. 'draft') in their pro…
OVR-012During capability negotiation (step 3, Extension Validation), businesses MUST exclude any extension whose parent capability is not present i…

Signals-Attribution-Eligibility 13

SAE-002All signal keys MUST use reverse-domain naming to ensure provenance and prevent collisions in the shared namespace
SAE-003Signal keys must match the reverse-domain identifier pattern (well-known dev.ucp namespace; extensions use their own)
SAE-007Numeric or boolean attribution values MUST be string-encoded as they would be in a URL query string
SAE-008The presence or absence of the attribution field MUST NOT affect the response or negotiation
SAE-010Eligibility values MUST use reverse-domain naming and MUST be non-identifying
SAE-011Businesses MUST ignore unrecognized eligibility values without error
SAE-012Eligibility and policy enforcement MUST occur at checkout time using binding transaction data (context is non-authoritative)
SAE-013All accepted eligibility claims MUST be resolved before the transaction can complete
SAE-014Unrecognized or inapplicable eligibility claims MUST NOT block the checkout
SAE-017At completion, accepted claims that remain unverified MUST result in type 'error' with code 'eligibility_invalid'
SAE-018Businesses MUST NOT complete a transaction with unresolved eligibility claims
SAE-019Eligibility verification failure MUST only affect the messages array
SAE-020On eligibility verification failure the Business MUST return an error in messages with code 'eligibility_invalid' and severity 'recoverable'

Version-Negotiation-And-Protocol-Errors 5

NEG-001When the platform's protocol version is unsupported, the business MUST return a version_unsupported error, mapped to HTTP 422 (REST).
NEG-002When no compatible capabilities exist in the intersection, the business MUST return a capabilities_incompatible error, mapped to HTTP 200 wi…
NEG-003A resolved-but-unfetchable profile (timeout/non-2xx) maps to profile_unreachable, HTTP 424.
NEG-004A fetched profile that is not valid JSON or violates schema maps to profile_malformed, HTTP 422.
NEG-005A request whose platform profile URL is malformed, MISSING, or unresolvable is rejected with invalid_profile_url (REST 400 / MCP -32001)