State of UCP: How We Count Verified Implementations
The evidence method behind the State of UCP dataset, including endpoint checks, official sources, verification dates, and legacy records.
The State of UCP separates implementation claims into four evidence states. A listing counts as a verified live implementation only when it is marked live and a public UCP endpoint or profile has passed at least one check.
Quick Answer
- Endpoint verified: A public endpoint or profile passed a check.
- Source verified: An official repository, document, or provider announcement supports the claim.
- Self-reported: The provider supplied the claim, but UCPList has not independently verified it.
- Unverified: The record does not have enough evidence for a stronger classification.
These states stay separate. An announcement does not increase the verified live count.
Why the count is narrow
UCP ecosystem pages often mix merchant endpoints, platform announcements, SDK repositories, related commerce tools, and community projects. A single large number can make the market look active while saying little about what a developer can call today.
The State of UCP uses one unit for the headline count: an independently deployable implementation. Duplicate records are collapsed by public endpoint or canonical implementation URL.
This makes the number smaller than the broader directory count. The directory maps the market. The State dataset measures what the available evidence supports.
Methodology
A verified live record needs both ucpStatus: live and evidenceStatus: endpoint-verified.
Endpoint verification is earned after one successful check. It does not expire automatically. The record keeps its verification date, and later check results are published when available.
Capabilities count only for endpoint-verified or source-verified records. A capability listed on an unverified or self-reported record does not contribute to the coverage table.
UCPList adopted the complete source, verification date, and evidence status contract on July 23, 2026. The historical migration is still in progress. Legacy records with a source and check date can appear in the State dataset, but the dataset labels them unverified when an explicit evidence classification is missing.
What the State page publishes
The canonical page includes a direct live count, sources and dates, capability coverage, URL-based filters, a material changelog, corrections, and current plus immutable JSON distributions.
The versioned JSON dataset is generated from the same records as the page.
Use the evidence filter before choosing an implementation target. Endpoint-verified records provide the strongest operational signal. Source-verified records are useful for official SDKs, protocol tools, and announced support. Unverified records are leads for further research, not proof of availability.
FAQ
Does an old successful check still count?
Yes. The date remains visible so you can decide whether to check it again before integrating.
Does an official announcement count as live?
No. It can qualify as source verified, but it does not increase the endpoint-verified live count.
Why publish unverified records?
They show where ecosystem coverage exists but the evidence is incomplete.
Can an agent use this dataset?
Yes. The current JSON URL follows the latest material release, and each release also has an immutable version URL.
Read next
How fast is UCP checkout compared to standard web checkout? Real benchmark data, where the latency comes from, and what it means for conversion.
A technical comparison of UCP checkout and headless commerce. When to use each, where they overlap, and how they work together.
REST APIs power most of e-commerce. So why do AI agents need UCP at all? The answer is in what REST was never designed to do.