The trust layer on apis.io used to be five pages that described one system without saying how they fit. This week it was consolidated around a single chain. There are six steps, from finding an API to being revocable somewhere else. Four are live. One is live but unproven. One is not built.
The problem the chain answers is stated in one sentence on the page. Every provider makes you fill in a form, because the form is where it collects what it needs to know about you, and an agent cannot fill in a form.
The chain, as the page states it
| Step | Status |
|---|---|
1. Find the API (RFC 9727 linkset at /.well-known/api-catalog) |
live |
| 2. Learn what it takes to get in (the onboarding descriptor) | live |
| 3. Get a credential with no human (five registration doors) | live |
| 4. Say who you are (KYA) | live |
| 5. Pay per call over x402 | live, unproven |
| 6. Revocation other providers hear about | not built |
Step 5 is the honest one. The page says per-call x402 settlement was verified on mainnet on 2026-09-17, that the first real paid call has not happened yet, and that buying a whole plan still needs a human. Step 6 is left unbuilt on purpose: pushing revocations before there is a population of anchored identities to revoke “would be theatre.”
The machine-readable version is the onboarding descriptor. Its gaps array currently holds five entries. The most candid one says the AAuth door has exactly one agent provider on its allowlist, and apis.io runs it. A probe of 1,486 hosts on 2026-08-30 found no other AAuth resource document anywhere in the catalog. The descriptor calls that “a worked example rather than an interoperating ecosystem,” which is the right label.
The two pages that argue against us
The seven roles defines Provider, Consumer, Principal, Directory, Attestation Source, Authorization Server and Supervisor by what each one does and what it owes. Each role is defined by its function, never by who fills it. apis.io fills two roles at once, Directory and Provider. The Supervisor slot is named and deliberately left empty. There is no regulator and no appeal beyond us, and the page would rather state that absence than imply one isn’t needed.
The conflict of interest names three places those two roles pull against each other: rating a competitor, gating enrolment, and using attestation as leverage. It then lists four constraints that actually hold. The rubric is public and every score is reproducible. Correction is free. Removals carry a stated basis. And our own record is scored by the same rubric. That record is currently 93.6, exemplar, with 77.5 on Agent Readiness, on the apis.io provider page.
The page also lists what was traded away when the framework became a product, not a standard in August. It used to promise attestations signed with a key separate from the one apis.io uses as a provider. It now says that sentence was dropped rather than quietly keeping it.
Observation
Most trust pages are written to reassure. These say they are written to be quoted against us, and they invite one check: if the page, the descriptor and the server disagree, that is a bug.
Takeaway
The number that would move this layer is the first real paid call at step 5, and a second agent provider on the AAuth allowlist. Until then, start at the chain and pick your door: onboarding if you run an agent, the blueprint if you run an API, and the rubric if you are deciding whether to believe any of it.
The whole system is on one screen at apis.io/trust/.