APIs.json 0.22 is a vocabulary release. It does not change the structure of an index — no new collections, no new required fields. What it changes is how much of the real world the specification is willing to recognise.
The measurement that prompted it
We counted every type value across 26,598 published APIs.json indexes — 332,345 property references in total — and validated them against the 0.21 schema. Only 67.6% passed.
The single most common invalid value, DomainSecurity, appears on 23,135 of those indexes. LLMsTxt appears on 6,926. AgenticAccess on 6,520. SignUp on 4,434. These are not typos or vendor inventions; they are the vocabulary publishers reached for when the specification had no word for what they were pointing at.
A format that a third of real usage fails is describing something other than the web it claims to index.
Sixty-four property types promoted
Two grounds, both stated so the reasoning can be argued with.
Measured use. Generic, cross-vendor types carried by at least 100 distinct organizations. Security and trust: DomainSecurity, VulnerabilityDisclosure, TrustCenter, WellKnown, SecurityTxt, OAuthScopes. Operations and developer experience: Lifecycle, Conventions, ErrorCatalog, DataModel, Packages, Idempotency, Components.
Design intent. Two surfaces the ecosystem needs declared even where publishing has not caught up. The agent surface — AgenticAccess, LLMsTxt, AgentSkill, AgentCard, A2A, APICatalog. And the open-source and supply-chain surface — SourceCode, Repository, HelmChart, DockerImage, ContributionGuide, CodeOfConduct, SecurityPolicy, Releases, IssueTracker, Contributors, Maintainers, SBOM, Attestation, Provenance.
That second group matters. An open-source project can be exemplary at everything open source is good at — a clear licence, a real contribution guide, signed releases, a published SBOM — and until now an APIs.json index had no way to say so.
Some candidates were deliberately left out. Company, Platform, Developer and Technology all appear on more than a hundred indexes and all were rejected: a property type that does not tell a consumer what to expect is worse than no type at all.
Synonyms are now valid
0.22 accepts recognised alternate spellings of types the specification already defines. Terms of Service beside TermsOfService. Sign Up beside SignUp. LlmsText beside LLMsTxt. Python SDK beside SDKs.
The canonical name is documented and publishers should prefer it. But a specification that accepts exactly one spelling of a word the world spells five ways does not make publishers more consistent — it pushes them into extensions, and a consumer then has to handle the variant anyway, without the specification's help.
Extensions accept x- as well as X-
0.21 permitted only capital X-. OpenAPI and JSON Schema both use lower case, and 311 organizations were publishing lower-case extensions that failed validation on nothing but the case of a letter. Both are now valid; lower case is preferred.
The result
93.5% of real-world property references now validate, up from 67.6%. The remainder are genuinely provider-specific and belong in extensions, which is what extensions are for.
The canonical specification text and JSON Schema live in the api-json repository as apisjson_0.22.txt and schema_0.22.yml. If a type you publish is still invalid and you think it should not be, open an issue — that is exactly the evidence this release was built from.