THE SHORT ANSWER
A UCP discovery profile describes a merchant’s supported capabilities and how a partner can reach them. Treat the profile as an interface contract: select a supported protocol version, declare only working capabilities, and test the advertised services before describing the integration as available.
Start with the capability you intend to support
Write down the customer action first: find products, look up a selected product, or continue a checkout. These actions create different engineering and operational responsibilities. A catalog export can support your data preparation, but it does not by itself provide a working protocol service.
Give every advertised capability an owner. That person should know which application serves requests, where its data comes from, and how failures are detected. This turns a profile review into an operational discussion instead of a JSON formatting exercise.
Match the profile to a tested version
UCP uses merchant discovery configuration at /.well-known/ucp. Read the documentation for the released version your partner supports. Keep a saved copy of that contract alongside your implementation; an example from a draft page is not evidence that your partner accepts it.
Record the version in your integration checklist, sample requests and change history. When upgrading, compare fields, transport details and error behavior. A successful response from an older client should be a deliberate compatibility decision, not an accidental consequence of permissive parsing.
Prove each advertised endpoint
Test the profile and its referenced service from outside your development environment. Follow the declared transport, resolve a real product and inspect how the service handles an unknown identifier. Check that price and availability agree with the merchant’s current selling experience.
A useful test record contains a timestamp, protocol version, request category, product identifier and response outcome. Remove credentials and personal data from shared evidence. A screenshot of valid configuration alone does not prove that the downstream service works.
Make configuration changes reviewable
Put profile changes through the same release process as service changes. Preview the difference, test the new endpoint and retain the previous configuration for a controlled recovery. Avoid advertising an unfinished capability while the team is still building its backing service.
Monitor both configuration reachability and meaningful requests. A reachable profile with a broken catalog lookup is still a broken shopping experience. Assign someone to investigate those failures and document the conditions under which the capability should be paused.
ILLUSTRATIVE WORKED EXAMPLE
Make it concrete.
Illustrative example: a homeware merchant first supports catalog lookup. Its release checklist verifies the discovery profile, one available mug, one unavailable variant and one unknown ID. Checkout remains outside the declared scope until its own service and partner tests are complete.
Your practical checklist
- Choose a partner-supported released version.
- List the exact shopping actions in scope.
- Assign an owner to every declared capability.
- Test advertised endpoints with known and unknown products.
- Save configuration changes and recovery instructions.
Common questions
Does a valid profile prove UCP compatibility?
It proves only part of the configuration. The advertised service, version and partner interaction still need testing.
Can I copy a documentation example unchanged?
Use it to understand the structure, then verify every version, capability and endpoint against your actual integration.
Sources & scope
Official references checked 29 October 2026. Examples are illustrative, not customer results. Platform requirements can change; use current destination documentation for implementation decisions.
Our editorial method & corrections ↗