THE SHORT ANSWER
UCP catalog capabilities help a platform search or retrieve product information. Checkout is a separate capability with transaction responsibilities. A catalog snapshot or working lookup response should be described at that scope, rather than presented as proof of a live purchasing flow.
Identify the action your service supports
Start with a plain-language action: search a category, retrieve an exact item or complete a purchase. Attach that action to the relevant current capability definition. This prevents a technical team from building a response that looks useful while a commercial team assumes a different customer experience.
Keep product and offer identity explicit in lookup tests. A request for one size should not return a generic parent result that silently changes the selection. Include unknown and unavailable items so the service’s failure behavior is understandable as well as its successful path.
Treat discovery as a live declaration
UCP uses a business profile to describe supported services and capabilities. The declaration needs to match what the service actually implements. Publishing a profile is not a substitute for implementing the behavior it advertises.
Review the capability and transport versions together with the current official documentation. A copied example may illustrate structure without being appropriate for your production scope. Keep the exact version references in the test record so future changes can be assessed deliberately.
Keep transaction claims behind a separate gate
A catalog response can help an agent understand products, but transaction work also needs a valid offer, applicable fulfillment and payment handling, and an order lifecycle. Test these through the actual intended integration when they are in scope.
Do not mark checkout enabled merely because a price and a link are present. Those facts are useful for discovery and a normal store handoff, but they do not prove that an agent-enabled transaction path is complete or approved.
Evaluate catalog tools at the right boundary
A preparation tool can help clean identities, selected options and descriptive data before a service is connected. It may also produce a structured snapshot for a prototype. Ask what happens between that artifact and the merchant-domain service the platform will call.
Feedaptor’s free variant checker is a useful small-sample diagnostic. The private workspace supports reviewed catalog work within its documented scope. Keep live UCP service deployment, capability conformance and transaction enablement as explicit requirements when deciding whether the product fits your project.
Separate the artifact, declaration and live service
A catalog snapshot contains prepared product information. A business profile describes what a business supports. A live catalog service handles the requests for the capabilities it actually implements. Treat these as separate deliverables with an owner and a test. Completing one does not establish that the others are operating.
The current UCP documentation describes capability discovery through the business profile at /.well-known/ucp. For an implementation, confirm the applicable version, declared capabilities and chosen transport with the consuming platform. Keep the production declaration aligned with tested behavior rather than copying every capability from an example profile.
| Deliverable | What it provides | What to demonstrate next |
|---|---|---|
| Prepared catalog snapshot | A product-data artifact for further integration | Identity, variant and offer checks against the source |
| Business profile | A declaration of supported services and capabilities | Retrieve the profile and verify it matches the deployed service |
| Catalog search or lookup | A running response path for the declared action | Known item, missing item, selected variant and error behavior |
| Checkout capability | A separate transaction responsibility | The intended purchasing and order flow under its own tests |
Use a small live-service acceptance plan
Choose known products with deliberately different cases: a normal product, two selected variants, an unavailable item and an unknown identifier. Write the expected outcome for each request. Inspect whether the service returns the right product and offer, preserves the requested selection and explains missing results according to the chosen binding. Record the request context and deployed version.
Add failure cases before describing the service as ready: an unavailable dependency, unsupported capability or version combination, and a declared action that is not implemented. Decide what the platform should see and who investigates the failure. Feed preparation remains valuable work, while live-service conformance and transaction readiness need their own evidence.
ILLUSTRATIVE WORKED EXAMPLE
Example: demonstrate an exact variant lookup while keeping checkout separate
Illustrative test: a catalog lookup returns the requested black size-42 shoe and a clear not-found result for an unknown ID. The team records lookup behavior as tested. Checkout remains unadvertised until its separate transaction flow can be demonstrated.
Your practical checklist
- Describe the supported action in plain language.
- Test exact variant lookup and failure cases.
- Match advertised capabilities to implemented behavior.
- Record the tested protocol and capability versions.
- Keep checkout behind its own acceptance gate.
Common questions
Does a UCP JSON snapshot make a live service?
No. A snapshot can be a preparation artifact. A live service needs the declared transport, endpoints and capability behavior.
Can catalog work proceed before checkout is ready?
Yes. Keep the milestones separate and describe each result accurately.
What should I ask a vendor claiming UCP support?
Ask which deliverable is implemented: a snapshot, a business profile, live catalog capabilities or checkout. Request the version, transport, destination dependencies and a demonstration of successful and failed requests at that scope.
Sources & scope
Primary references below show their latest recorded check date. Examples are illustrative, not customer results. Use the current destination documentation for implementation decisions.