11 Well-Known Manifest UCP Examples That Validate (2026)

A few months back we were handed a storefront that looked, on paper, completely UCP-ready. The merchant had deployed a file at `/.well-known/ucp.json`, the DNS resolved, the TLS cert was valid, and their internal team swore the integration was “done.” Then an agent tried to actually read it. The manifest returned a 200, but the JSON was malformed at the `endpoints` block, the `version` field used a string where a semantic version was expected, and the whole thing silently fell out of every agent’s discovery crawl. Nobody noticed for the better part of a week because the store still worked fine for human shoppers. That is the problem with a bad well-known manifest UCP example: it fails quietly, and the merchant is the last to find out.

We build and repair this infrastructure every week, and the single most common request we get is deceptively simple: “Can you just show me a real well-known manifest UCP example that works?” Public spec pages will show you the field definitions. They will not show you the ordering mistakes, the content-type headers that break strict parsers, or the version pinning choices that quietly lock you out of newer agents. This article is our answer. Below are eleven manifest patterns, ordered roughly by how often they matter, each with the concrete detail we have learned the hard way. We will also walk through the framework we use to validate every file before it ships, and how we measure whether the thing is actually working at 30, 60, and 90 days.

TL;DR

Minimum viable manifest wins first: A valid well-known manifest UCP example served at `/.well-known/ucp.json` with correct `content-type: application/json`, a semantic `version`, and reachable `endpoints` is the single highest-leverage thing you can ship, and most broken deployments fail on exactly these three fields.
Validation is not completion: According to UCP Checker, which independently monitors 23,390+ storefronts, roughly 70% pass full UCP validation (16,376 verified), but a conformant manifest is not the same as an agent being able to complete a real checkout, so treat validation as the floor and transaction success as the ceiling.
Examples beat specifications: Reading the spec teaches you the fields; reading real manifest examples teaches you the failure modes, which is why every pattern below is drawn from files we have actually deployed, debugged, or rescued.

Why the Well-Known Manifest Is the Whole Ballgame

Before the list, the context that makes it make sense. The well-known manifest is the first thing any AI shopping agent requests when it encounters your domain. It is the handshake. If an agent cannot find, parse, and trust your manifest, nothing downstream matters: not your product feed, not your checkout, not your pricing. We tell every client the same thing we will tell you here: the manifest is a public contract, and agents read it literally and unforgivingly.

If you want the conceptual grounding before the examples, our definitive guide to what UCP is covers the protocol end to end, and the UCP technical architecture deep dive explains where the manifest sits in the request flow. The examples below assume you already know the manifest matters. Now we show you what good ones look like.

1. The Minimum Viable Manifest That Actually Validates

Start here. The most useful well-known manifest UCP example is not the most complete one, it is the smallest one that passes validation and gets you discovered. We ship this first for almost every merchant, then layer on the rest.

{ "ucp_version": "1.0.0", "name": "Northwind Supply Co.", "canonical_domain": "https://northwind.example", "endpoints": { "catalog": "https://northwind.example/ucp/catalog", "checkout": "https://northwind.example/ucp/checkout" }, "capabilities": ["catalog.read", "checkout.create"], "updated_at": "2026-02-10T14:00:00Z" }

What makes this validate: the `ucp_version` is a semantic version string, not a bare integer or a label like “latest.” The `canonical_domain` is absolute and HTTPS. The `endpoints` are fully qualified URLs, not relative paths. Every one of those is a field we have personally watched break a deployment.

Best for: merchants who want to get discoverable this week and iterate, rather than spending a month perfecting a manifest that nobody can read yet.

Serve this at `https://yourdomain.com/.well-known/ucp.json` with `content-type: application/json`. If your server defaults to `text/plain` for `.json` in that directory, which several misconfigured Nginx setups do, strict agent parsers will reject it even though the body is perfect valid JSON.

2. The Versioned Manifest That Does Not Break on Protocol Updates

The second pattern solves the problem that bites merchants six months in: the protocol moves and their manifest does not. A well-known manifest UCP example that pins versions deliberately will survive a protocol bump; one that assumes “latest” everywhere will not.

{ "ucp_version": "1.1.0", "supported_versions": ["1.0.0", "1.1.0"], "name": "Harborlight Goods", "canonical_domain": "https://harborlight.example", "endpoints": { "catalog": "https://harborlight.example/ucp/v1/catalog", "checkout": "https://harborlight.example/ucp/v1/checkout" }, "capabilities": ["catalog.read", "checkout.create", "order.status"], "updated_at": "2026-02-18T09:30:00Z" }

What makes this robust: the `supported_versions` array tells agents you can negotiate down to 1.0.0 if they do not speak 1.1.0 yet. In our experience, that single array has prevented more silent agent drop-offs than any other field. We saw one merchant lose roughly a quarter of their agent traffic over a weekend because they jumped straight to a new minor version without declaring backward compatibility.

Standout feature: version negotiation, which means older agents keep working while you adopt new capabilities.

Our take: pin your version path in the endpoint URL too, as this example does with `/ucp/v1/`. When you ship v2 endpoints, old agents keep hitting v1 and nothing breaks.

3. The Authenticated Manifest With Signed Trust Metadata

Discovery is step one. Trust is step two. Once agents can find you, the next thing sophisticated ones check is whether they can trust the manifest’s claims. This well-known manifest UCP example adds the trust block we recommend for any merchant handling real payment flows.

{ "ucp_version": "1.1.0", "name": "Meridian Outfitters", "canonical_domain": "https://meridian.example", "endpoints": { "catalog": "https://meridian.example/ucp/catalog", "checkout": "https://meridian.example/ucp/checkout" }, "capabilities": ["catalog.read", "checkout.create", "payment.tokenize"], "trust": { "verification_url": "https://meridian.example/.well-known/ucp-verify", "key_id": "meridian-2026-q1", "signature_algorithm": "ed25519" }, "updated_at": "2026-02-20T11:00:00Z" }

What makes this matter: the `trust` block lets an agent verify that the manifest it fetched was actually published by the domain owner and not injected by a man-in-the-middle. The `key_id` scheme here is deliberately quarterly, which maps to our recommended rotation schedule.

Rotation schedule: we rotate signing keys every 90 days and keep the previous key valid for a 14-day overlap window so in-flight agent sessions do not fail mid-transaction. Name your keys by quarter, as above, so the rotation is self-documenting.

Best for: merchants whose manifests expose `payment.tokenize` or any capability that touches money, where a spoofed manifest is a genuine fraud vector.

4. The Multi-Endpoint Manifest for Full Catalog and Order Coverage

Thin manifests get you found. Complete manifests get you transacted with. This pattern is the one we deploy once a merchant is serious about agentic commerce rather than just experimenting.

{ "ucp_version": "1.1.0", "name": "Cedar & Pine Home", "canonical_domain": "https://cedarpine.example", "endpoints": { "catalog": "https://cedarpine.example/ucp/catalog", "product": "https://cedarpine.example/ucp/product/{id}", "search": "https://cedarpine.example/ucp/search", "checkout": "https://cedarpine.example/ucp/checkout", "cart": "https://cedarpine.example/ucp/cart", "order": "https://cedarpine.example/ucp/order/{id}", "inventory": "https://cedarpine.example/ucp/inventory" }, "capabilities": [ "catalog.read", "product.read", "search.query", "cart.manage", "checkout.create", "order.status", "inventory.read" ], "rate_limits": { "default": "100/minute", "search": "30/minute" }, "updated_at": "2026-02-22T16:45:00Z" }

What makes this production-grade: the `{id}` templating in `product` and `order` tells agents how to construct deep links without crawling your entire catalog, and the `rate_limits` block keeps an overeager agent from hammering your search endpoint. We have found that declaring rate limits explicitly reduces accidental self-inflicted outages more than any amount of server-side throttling, because well-behaved agents respect the declared number and back off.

Standout feature: endpoint templating with `{id}`, which cuts agent crawl load dramatically on large catalogs.

If you are on Shopify, much of this structure maps to what the platform can expose through our Shopify UCP integration guide, and WooCommerce merchants should read the WooCommerce UCP integration guide for the equivalent endpoint mapping.

5. The Localized Manifest for Multi-Region Storefronts

Merchants selling into multiple regions trip over currency and language more than anything else. A single-currency manifest will get you partial agent coverage; a localized one gets you the whole addressable market. This well-known manifest UCP example declares its locales explicitly.

{ "ucp_version": "1.1.0", "name": "Aurora Living", "canonical_domain": "https://auroraliving.example", "endpoints": { "catalog": "https://auroraliving.example/ucp/catalog", "checkout": "https://auroraliving.example/ucp/checkout" }, "capabilities": ["catalog.read", "checkout.create"], "locales": { "supported": ["en-US", "en-GB", "de-DE", "fr-FR"], "default": "en-US", "currency_map": { "en-US": "USD", "en-GB": "GBP", "de-DE": "EUR", "fr-FR": "EUR" } }, "updated_at": "2026-02-24T08:15:00Z" }

What makes this complete: the `currency_map` removes the single biggest source of agent confusion we see in cross-border commerce, where an agent assumes USD because nothing told it otherwise and then presents a wildly wrong price to a shopper. Declaring the map means the agent fetches the right price in the right currency on the first request.

Best for: cross-border merchants and anyone whose checkout already supports multiple currencies but whose manifest silently hides that from agents.

Our take: list only locales you can actually fulfill and price correctly. Declaring `fr-FR` support and then returning English product data is worse than not declaring it, because the agent trusts your manifest literally.

6. The Capability-Gated Manifest for Phased Rollouts

Not every merchant wants agents completing full purchases on day one. We frequently ship a read-only manifest first, let the merchant watch agent traffic for a few weeks, then unlock transactional capabilities. This pattern makes that phased approach explicit and safe.

{ "ucp_version": "1.1.0", "name": "Thistle & Vine", "canonical_domain": "https://thistlevine.example", "endpoints": { "catalog": "https://thistlevine.example/ucp/catalog", "product": "https://thistlevine.example/ucp/product/{id}" }, "capabilities": ["catalog.read", "product.read"], "roadmap": { "checkout.create": "2026-Q2", "cart.manage": "2026-Q2" }, "updated_at": "2026-02-26T13:00:00Z" }

What makes this strategic: the `roadmap` block is optional but powerful. It signals to agents and to agent-platform operators that transactional capabilities are coming, which some platforms use to prioritize re-crawling your domain. Meanwhile, the `capabilities` array contains only what you can actually serve today, so no agent attempts a checkout that would fail.

Standout feature: the `roadmap` block, which lets you declare intent without declaring capabilities you cannot yet honor.

We tell clients this is the honest way to launch. Declaring `checkout.create` before your checkout endpoint is bulletproof is how you end up with the three-day silent failure from the opening of this article.

7. The Shopify-Native Manifest Pattern

Because the installed base skews so heavily toward one platform, this pattern deserves its own entry. According to UCP Checker, which independently monitors 23,390+ storefronts, roughly 70% pass full UCP validation (16,376 verified), and that population skews heavily to Shopify, so the Shopify-shaped manifest is the one most agents encounter most often. Important caveat: passing validation is not the same as an agent being able to complete a real checkout, and we see plenty of validated Shopify manifests whose checkout flow still fails under real agent sessions.

{ "ucp_version": "1.1.0", "name": "Lumen Apparel", "canonical_domain": "https://lumenapparel.example", "platform": { "name": "shopify", "adapter_version": "2026.1" }, "endpoints": { "catalog": "https://lumenapparel.example/ucp/catalog", "checkout": "https://lumenapparel.example/ucp/checkout" }, "capabilities": ["catalog.read", "checkout.create", "order.status"], "updated_at": "2026-02-28T10:30:00Z" }

What makes this useful: the `platform` block tells agents which adapter semantics to expect, which lets sophisticated agents apply platform-specific handling. The checkout quirks of a Shopify-backed endpoint differ from a custom-built one, and declaring the platform saves the agent a round of probing.

Best for: the large majority of merchants running on Shopify who want agents to apply the correct platform assumptions immediately.

Pair this manifest with the full Shopify UCP integration guide before you flip `checkout.create` to live, because validation passing and checkout completing are, as noted, two very different milestones.

8. The Manifest With Explicit Agent Policy and Terms

As agents become primary shoppers, merchants increasingly want to express rules: which agents may transact, what the return policy is, whether automated bulk buying is allowed. This pattern bakes policy into the manifest so agents can honor it programmatically.

{ "ucp_version": "1.1.0", "name": "Ridgeway Tools", "canonical_domain": "https://ridgeway.example", "endpoints": { "catalog": "https://ridgeway.example/ucp/catalog", "checkout": "https://ridgeway.example/ucp/checkout" }, "capabilities": ["catalog.read", "checkout.create"], "policy": { "terms_url": "https://ridgeway.example/ucp/terms", "max_order_quantity": 50, "returns_window_days": 30, "agent_allowlist_url": "https://ridgeway.example/.well-known/ucp-agents" }, "updated_at": "2026-03-01T12:00:00Z" }

What makes this forward-looking: the `max_order_quantity` field is the one we recommend most often to merchants worried about automated scalping, because it gives agents a hard ceiling they are expected to respect before even attempting checkout. The `agent_allowlist_url` is for merchants who want to go further and only transact with approved agent operators.

Standout feature: `max_order_quantity`, a single number that heads off the inventory-draining bulk-buy scenario many merchants fear about agentic commerce.

This is exactly the territory our analysis of what happens when AI agents become the primary shoppers explores in depth. The policy block is where merchant control lives.

9. The Feed-Linked Manifest for Machine-Readable Product Data

A manifest tells agents how to talk to you; a product feed tells them what you sell. Linking the two from the manifest means agents can bulk-ingest your catalog without hammering per-product endpoints. This is a pattern we deploy for any merchant with more than a few hundred SKUs.

{ "ucp_version": "1.1.0", "name": "Fernbrook Pantry", "canonical_domain": "https://fernbrook.example", "endpoints": { "catalog": "https://fernbrook.example/ucp/catalog", "checkout": "https://fernbrook.example/ucp/checkout" }, "capabilities": ["catalog.read", "checkout.create", "feed.read"], "feeds": { "product": { "url": "https://fernbrook.example/ucp/feed/products.json", "format": "ucp-product-feed-1.0", "refresh_interval": "15m" } }, "updated_at": "2026-03-02T07:00:00Z" }

What makes this efficient: the `refresh_interval` tells agents how often the feed changes so they cache intelligently instead of re-fetching constantly. We set this to match the merchant’s actual inventory update cadence; a 15-minute interval on a store that updates stock hourly just wastes everyone’s bandwidth.

Best for: catalog-heavy merchants where per-product crawling would be slow, expensive, or rate-limited.

The shift from human-readable pages to machine-readable feeds is the central theme of the rise of machine-readable commerce, and the feed-linked manifest is how you participate in it.

The manifest is a public contract that agents read literally and unforgivingly, so the only well-known manifest UCP example worth shipping is one you have watched a real agent parse and complete a real checkout against.

10. The Health-Checkable Manifest for Monitoring and Alerts

The opening story of this article, a manifest failing silently for most of a week, is the exact failure this pattern prevents. We never ship a production manifest without a declared health endpoint anymore, because the alternative is finding out about breakage from a confused merchant instead of from monitoring.

{ "ucp_version": "1.1.0", "name": "Blackwater Coffee", "canonical_domain": "https://blackwater.example", "endpoints": { "catalog": "https://blackwater.example/ucp/catalog", "checkout": "https://blackwater.example/ucp/checkout", "health": "https://blackwater.example/ucp/health" }, "capabilities": ["catalog.read", "checkout.create"], "monitoring": { "status_url": "https://status.blackwater.example", "health_check_interval": "60s" }, "updated_at": "2026-03-03T15:20:00Z" }

What makes this operationally sound: the `health` endpoint gives both agents and your own monitoring a cheap, dedicated way to confirm the UCP surface is alive without running a full catalog or checkout request. We poll it every 60 seconds and alert if we see two consecutive failures, which gives us a time to detection of roughly two minutes rather than three days.

Reduce time to detection: poll the declared `health` endpoint on a 60-second interval and alert on two consecutive failures, which catches silent breakage within about two minutes.

Standout feature: a dedicated health endpoint, the single cheapest insurance against the silent-failure scenario that costs merchants real revenue.

11. The Fully Loaded Reference Manifest

Finally, the comprehensive example we point clients to as the north star. You will not ship all of this on day one, and you should not try. But when a merchant asks what a mature, complete well-known manifest UCP example looks like, this is the file we show them.

{ "ucp_version": "1.1.0", "supported_versions": ["1.0.0", "1.1.0"], "name": "Summit & Shore Mercantile", "canonical_domain": "https://summitshore.example", "platform": { "name": "shopify", "adapter_version": "2026.1" }, "endpoints": { "catalog": "https://summitshore.example/ucp/catalog", "product": "https://summitshore.example/ucp/product/{id}", "search": "https://summitshore.example/ucp/search", "cart": "https://summitshore.example/ucp/cart", "checkout": "https://summitshore.example/ucp/checkout", "order": "https://summitshore.example/ucp/order/{id}", "inventory": "https://summitshore.example/ucp/inventory", "health": "https://summitshore.example/ucp/health" }, "capabilities": [ "catalog.read", "product.read", "search.query", "cart.manage", "checkout.create", "order.status", "inventory.read", "payment.tokenize" ], "trust": { "verification_url": "https://summitshore.example/.well-known/ucp-verify", "key_id": "summitshore-2026-q1", "signature_algorithm": "ed25519" }, "locales": { "supported": ["en-US", "en-CA"], "default": "en-US", "currency_map": { "en-US": "USD", "en-CA": "CAD" } }, "feeds": { "product": { "url": "https://summitshore.example/ucp/feed/products.json", "format": "ucp-product-feed-1.0", "refresh_interval": "15m" } }, "policy": { "terms_url": "https://summitshore.example/ucp/terms", "max_order_quantity": 25, "returns_window_days": 30 }, "rate_limits": { "default": "100/minute", "search": "30/minute" }, "monitoring": { "status_url": "https://status.summitshore.example", "health_check_interval": "60s" }, "updated_at": "2026-03-04T09:00:00Z" }

What makes this the reference: every pattern from the previous ten entries is present and internally consistent. Version negotiation, trust metadata, localization, feeds, policy, rate limits, and monitoring all coexist without contradiction. This is the manifest of a merchant who is treating agentic commerce as a real channel, not an experiment.

Best for: mature merchants who have already validated the basics and want the complete surface that sophisticated agent platforms reward with higher transaction priority.

Build toward this. Do not start here.

Checklist for choosing your manifest pattern:

Start minimal: Ship pattern 1 first, validate it, and confirm an agent can actually read it before adding anything else.
Add version negotiation early: Include `supported_versions` from the second iteration so protocol updates never silently drop your agent traffic.
Gate by capability honestly: Only declare capabilities whose endpoints you have tested end to end under real agent sessions.
Add trust before payment: Include the `trust` block before you ever declare `payment.tokenize`.
Always ship health: Never run a production manifest without a declared `health` endpoint and monitoring on a 60-second interval.
Localize only what you fulfill: Declare locales and currencies you can actually serve correctly, nothing aspirational.

The CLEAR Framework We Use to Validate Every Manifest

We do not eyeball manifests and hope. Every file we ship runs through a repeatable process we call CLEAR. Here is the full five-step framework, with what each step achieves.

Step one, Confirm reachability. What this achieves: it proves the manifest exists where agents expect it before you waste time on content. Fetch `https://yourdomain.com/.well-known/ucp.json` from outside your network, confirm a 200 status, confirm `content-type: application/json`, and confirm TLS is valid with no mixed-content warnings. Roughly a third of the broken deployments we rescue fail right here, usually on content-type or a redirect that strips the path.

Step two, Lint the structure. What this achieves: it catches malformed JSON and schema violations before any agent does. Run the file through a strict JSON parser, then validate every field type against the spec: `ucp_version` as semantic version, `endpoints` as absolute HTTPS URLs, `capabilities` as a known enum. A single trailing comma or a stringified number is enough to drop you from discovery.

Step three, Exercise the endpoints. What this achieves: it verifies that every URL the manifest promises actually responds correctly. For each declared endpoint, send a real request and confirm it returns the expected shape. A manifest that declares `checkout.create` but whose checkout endpoint 404s is worse than one that never declared it, because the agent trusts the declaration.

Step four, Attempt a real transaction. What this achieves: it closes the gap between validation and reality, which is the gap most merchants never test. Run an actual agent session, or a scripted stand-in, through catalog to cart to checkout. This is the step that separates a manifest that passes UCP Checker from a storefront an agent can actually buy from, and in our experience the two diverge more often than merchants expect.

Step five, Register monitoring. What this achieves: it guarantees you learn about breakage in minutes instead of days. Wire the declared `health` endpoint into your alerting with a 60-second poll and a two-failure threshold. This is how you make sure the opening story of this article never becomes your story.

Checklist for running CLEAR:

Fetch externally: Always validate from outside your own network, where agents actually sit.
Enforce content-type: Confirm `application/json` explicitly, not just a valid JSON body.
Validate every type: Treat `ucp_version`, `endpoints`, and `capabilities` as the three highest-risk fields.
Test one real checkout: Do not declare a transactional capability you have not completed end to end.
Alert in minutes: Poll health every 60 seconds and alert on two consecutive failures.

Let Our Team Ship a Manifest That Actually Transacts

We have debugged enough silent manifest failures to know that the gap between “validates” and “an agent can buy from this store” is where merchants lose real revenue. UCPhub’s Universal Commerce Protocol platform handles the full manifest lifecycle for you: generation, validation, signed trust metadata, health monitoring, and the end-to-end checkout testing that proves an agent can actually complete a purchase, not just read a file. If you want a manifest you have watched a real agent transact against rather than one you are hoping works, talk to our team and we will get your storefront agent-ready. You can also explore the UCPhub platform overview to see how the pieces fit together.

Measuring Success: 30, 60, and 90 Day KPIs

A manifest is not a one-time deliverable, it is a channel you grow. Here is how we measure whether a well-known manifest UCP example is actually earning its keep, broken out by horizon.

First 30 days, discovery and validation:

Validation pass rate: Target 100% pass against a strict validator within the first week; anything less means a field-level defect you should fix before measuring anything else.
Agent crawl frequency: Confirm at least one major agent platform is fetching your manifest within 30 days, visible in your access logs by the `/.well-known/ucp.json` request pattern.
Health uptime: Hold the declared health endpoint at 99.9% or better, measured on your 60-second poll.
Time to detection: Verify your alerting actually fires by forcing a controlled failure; you want detection under five minutes.

Days 30 to 60, engagement:

Endpoint hit distribution: Watch which endpoints agents actually request; if `search` and `product` dominate but `checkout` is never touched, your transactional surface is not being trusted yet.
Capability coverage used: Measure the share of declared capabilities that agents actually exercise, and prune or fix any that are declared but never called.
First completed agent transaction: The single most important milestone, the day a real agent completes a real checkout, which should land in this window if your CLEAR step four passed.

Days 60 to 90, scale and optimization:

Agent transaction volume: Track week-over-week growth in completed agent checkouts; a healthy manifest shows a rising line, not a flat one.
Transaction success rate: Of agent checkout attempts, what share complete? Below 90% points to a checkout endpoint problem, not a manifest problem.
Rate-limit incidents: Confirm your declared `rate_limits` are keeping agents within bounds with zero self-inflicted outages.
Version negotiation events: Watch how often agents fall back to an older `supported_versions` entry, which tells you when it is safe to drop legacy support.

Where These Examples Fit in the Bigger Picture

If you are just getting started, do not try to deploy the fully loaded reference manifest from entry eleven. Ship entry one, the minimum viable manifest, run it through the CLEAR framework, and confirm an agent can read it. Get that single file validated and monitored before you add trust blocks, feeds, or policy. Momentum from a working minimal manifest beats a perfect manifest that never ships. If instead you are auditing something that already exists, start at CLEAR step four and attempt a real transaction, because a manifest that validates but cannot complete a checkout is the most common and most expensive failure we find, and it is invisible until you test it. For the strategic context of why this channel matters at all, our guide to implementing Universal Commerce Protocol and our broader Universal Commerce Protocol insights are the best next reads.

Next Steps:

Deploy and fetch: Put a minimum viable manifest at `/.well-known/ucp.json` today and fetch it from outside your network to confirm a 200 with `application/json`.
Run one real checkout: Before declaring any transactional capability live, run a single end-to-end agent checkout against it.
Wire up monitoring: Add a health endpoint and alert on two consecutive 60-second failures so you never discover breakage from a confused customer.

Frequently Asked Questions

Can you show me an example of a UCP well-known manifest?

Yes, and this entire article is built around exactly that request because it is the one we hear most often. The quickest answer is entry one above, the minimum viable manifest: a JSON file with a semantic `ucp_version`, an absolute HTTPS `canonical_domain`, fully qualified `endpoints`, and a `capabilities` array, served at `/.well-known/ucp.json` with `content-type: application/json`. That file alone will validate and get you discovered by agents.

The reason we show eleven examples rather than one is that a single example teaches you the shape but not the failure modes. The difference between a manifest that validates and a manifest an agent can actually transact against lives in the details: version negotiation, trust metadata, honest capability declaration, and a health endpoint. Copy entry one to start, then layer on the patterns from entries two through eleven as your needs grow.

One caution we give every client: do not copy the fully loaded reference manifest from entry eleven as your starting point. It contains capabilities and endpoints you almost certainly cannot serve yet, and declaring capabilities you cannot honor is worse than declaring a smaller, honest surface.

What does a proper UCP manifest look like?

A proper manifest is valid, honest, and reachable, in that order. Valid means it parses as strict JSON and every field matches the expected type, with `ucp_version` as a semantic version string rather than a bare integer or the word “latest.” Honest means every capability it declares corresponds to an endpoint you have tested end to end; a manifest that promises `checkout.create` but whose checkout endpoint fails is improper no matter how clean the JSON looks. Reachable means it lives at `/.well-known/ucp.json`, returns a 200, and serves the correct content-type over valid TLS.

Beyond those three fundamentals, a proper manifest for a serious merchant also includes `supported_versions` for protocol resilience, a `trust` block if it touches payments, and a `health` endpoint for monitoring. The fully loaded reference in entry eleven shows all of these coexisting consistently, which is the other mark of a proper manifest: internal consistency, where the currency map matches the declared locales and the capabilities match the declared endpoints.

In our experience the most common way a manifest looks improper to an agent even when it looks fine to a human is the content-type header. A perfectly valid JSON body served as `text/plain` gets rejected by strict parsers, so always confirm the header explicitly.

Where can I find UCP manifest examples?

The examples in this article are drawn from manifests we have actually deployed, debugged, or rescued for real merchants, so they emphasize the patterns that matter in production rather than only the fields defined in the spec. Start with the minimum viable manifest in entry one and work up to the reference manifest in entry eleven depending on how mature your agentic commerce setup is.

For platform-specific examples, our Shopify UCP integration guide and WooCommerce UCP integration guide show how the generic manifest patterns map onto those specific platforms, which matters because the checkout semantics differ. The public UCP specification is the authoritative source for field definitions, but as we note throughout, the spec teaches fields while examples teach failure modes.

A practical tip: tools that monitor live storefronts can show you real manifests in the wild. Just remember that a manifest passing a validator is not proof that an agent can complete a checkout against it, so treat found examples as structural references rather than guarantees of working transactional flow.

How often should I update my UCP manifest?

Update the `updated_at` timestamp any time the substance of the manifest changes, and treat the manifest itself as a living document rather than a one-time deliverable. In practice we see substantive changes in two situations: when you add or remove a capability, and when the protocol version you support changes. Both should bump the timestamp so agents and monitoring systems know to re-evaluate.

For signing keys in the `trust` block, we recommend a 90-day rotation with a 14-day overlap window where the previous key remains valid, so in-flight agent sessions do not fail mid-transaction. Name keys by quarter so the rotation is self-documenting, as in the entry three example.

The feed refresh interval is a separate cadence. Set `refresh_interval` to match your actual inventory update frequency, not aspirationally. A 15-minute interval on a store that only updates stock hourly just wastes bandwidth and teaches agents to distrust your freshness signals.

Does passing validation mean agents can buy from my store?

No, and this is the most important distinction in the entire article. According to UCP Checker, which independently monitors 23,390+ storefronts, roughly 70% pass full UCP validation (16,376 verified), but that figure describes the population UCP Checker tracks, which skews heavily toward Shopify, and passing validation is not the same as an agent being able to complete a real checkout. We have seen validated manifests whose checkout flow still breaks under real agent sessions.

Validation confirms your manifest is structurally correct and reachable. It does not confirm that your checkout endpoint handles an agent’s request correctly, that your inventory data is accurate, or that payment tokenization completes. Those only surface when you run an actual transaction, which is step four of our CLEAR framework and the step we consider non-negotiable before declaring any transactional capability live.

Think of validation as the floor and a completed agent transaction as the ceiling. The gap between them is exactly where merchants lose revenue silently, and closing that gap is the whole point of testing with real agent sessions rather than trusting a green checkmark.

Do I need the trust block if I am not handling payments directly?

If your manifest does not declare any capability that touches money, you can launch without the `trust` block and still be fully valid and discoverable. Many merchants start with read-only manifests, entries one and six above, and those do not strictly require signed trust metadata to work.

That said, we recommend adding the trust block before you declare `payment.tokenize` or any capability where a spoofed manifest becomes a fraud vector. The trust block lets an agent verify that the manifest it fetched was genuinely published by the domain owner and not injected in transit. For a read-only catalog manifest the stakes of spoofing are low; for a transactional one they are high.

Our phased rollout approach handles this naturally. Launch read-only, watch agent traffic, then add the trust block in the same iteration where you unlock transactional capabilities. That way you are never exposing a payment-touching surface without the verification layer that protects it.

What happens if my manifest breaks after it has been working?

This is the exact scenario that opens this article, and the honest answer is that without monitoring, you often will not find out for days because the store keeps working fine for human shoppers while agents silently drop out. That lag is pure lost revenue on the agent channel, and it is entirely preventable.

The fix is the `health` endpoint and monitoring pattern from entry ten. Declare a dedicated health endpoint, poll it every 60 seconds, and alert on two consecutive failures. That configuration gives you a time to detection of roughly two minutes instead of three days. We never ship a production manifest without it anymore, precisely because we have lived through the silent-failure version.

Common breakage causes we see include a deploy that resets the content-type header, a certificate renewal that fails and breaks TLS, an endpoint refactor that moves a URL the manifest still points at, and a JSON edit that introduces a trailing comma. All four are invisible to human shoppers and all four are caught immediately by health monitoring plus the CLEAR validation process run on every change.