Kin Score
Kin Score is the API Evangelist rating system — a transparent, machine-readable rating that measures how complete an API is for developers and how safely it can be driven by AI agents. The rubric, the two scores, and where it runs.
I have spent my whole career forming opinions about whether an API is any good — not whether the company is valuable or the product is clever, but the narrower, more useful question of whether I can find it, understand it, trust how it behaves, and integrate it without a human beside me filling in what the documentation left out. I made that judgment thousands of times in my head before I finally wrote it down. The result is Kin Score — the API Evangelist rating system: a transparent, machine-readable rubric that scores a provider's public API surface so my sixteen years of opinions about APIs scale, travel, and can be argued with by anyone.
Every input is an artifact the provider actually publishes — an OpenAPI contract with real descriptions and error responses, a change log, documented rate limits, plans a buyer can read without a sales call. There is no panel, no vibes, and no pay-to-play tier that buys a better number. The whole rubric is out in the open, so any provider can see exactly why they scored what they scored and precisely what would move them up.
Two scores, on purpose
Composite quality is what people expect: how complete, transparent, and integration-ready an API is for a human developer — a weighted blend of six always-on facets and 111 individual checks, plus two conditional facets that apply only where they can mean something. Deliberately blunt, because the point is comparability, not a certificate.
Agent readiness is scored separately, because a human developer papers over an enormous amount of API friction that an autonomous agent cannot. Every implicit convention a human silently absorbs — ambiguous errors, undocumented idempotency, prose-only auth — is a place an agent retries blindly, double-charges a card, or hallucinates a payload. It lives on its own axis because a provider can be thin for humans yet ready for agents, or strong for humans yet useless to their agents.
Composite quality bands
A provider's composite score (0–100) maps to one of 6 bands, calibrated against the real distribution of the catalog rather than picked round. The share column is what each band actually holds today.
| Exemplar | 66.5+ 1.0% | Reference-quality API operations across every facet — a rich contract, published governance, transparent operations, and machine-readable commercial terms. The top ~1% of the catalog, and the band no provider reaches by accident. |
| Strong | 54.3 – 66.4 3.8% | Solid contracts, transparent operations, and an easy start. Typically complete on four or five facets with one clear soft spot — most often governance or a missing commercial artifact. |
| Developing | 39.3 – 54.2 13.3% | Real signal across most facets with visible, nameable gaps. The contract exists but is thin on descriptions or examples, or the portal is good while governance and commercial terms are absent. |
| Thin | 26.2 – 39.2 15.9% | Limited machine-readable signal and partial portal coverage. Usually a provider with documentation a human can read but little a machine or agent can consume without scraping. |
| Emerging | 11 – 26.1 24.0% | More than an index entry, but the surface is still mostly links rather than artifacts. These providers have started publishing — a portal, a few common links, maybe a spec — and are the cohort most likely to move a full band from modest, well-targeted work. |
| Minimal | 0 – 10.9 41.9% | Index entry only; little beyond a description and a link. Nothing here is machine-readable enough for an agent to act on without a human first reading the site. |
What changed in v0.14.0. THREE CHECKS THAT MEASURED THE WRONG THING. No new dimensions and no weightchanges, so the denominator is unmoved and nothing is rescaled. Two of themmove real populations, which is what makes this a release and not a patch.llms_txt_published no longer pays a provider for a file WE wrote. The checkasked existence and size, and the enrichment pipeline generates these filesinto all//llms/ — 2,755 of the 8,976 providers holding one carry amarker saying so, whether a `method: generated` line, an explicit generationsentence, or a section heading only we emit. A provider's own llms.txt doesnot contain a section call... Read the full rubric →
The facets
The composite is a weighted blend of facets, each scored 0–100 from its own checks. The weights decide what "good" means. Six apply to every provider and sum to 100%; two are conditional and apply only where they can mean something — regulatory posture to providers in a regulated industry, open source to providers whose product is itself open source.
| Contract Quality | Technical depth and richness of the API contract artifacts — OpenAPI, AsyncAPI, JSON Schema, JSON-LD. | 25% |
| Developer Ergonomics | How easy is it to get started? SDKs, CLI, portal, getting-started, documentation, sandbox/console, MCP server, and authentication clarity. | 20% |
| Access Clarity | What it costs, what you are permitted to do, and how you get in — plans, pricing, sign-up, terms of service, privacy, finops mapping, compliance/trust. Renam... | 20% |
| Operational Transparency | Does the provider expose how the API behaves operationally? Rate limits, status, change log, deprecation, security disclosure. | 13% |
| Contract Governance | Artifacts that describe and constrain the CONTRACT — rulesets, vocabulary, declared conformance, overlays. Renamed in 0.12 from "Governance": it never measur... | 12% |
| Discoverability | Can the API be found and understood from machine-readable metadata alone? Driven by apis.yml completeness, tagging, and identity signals. | 10% |
| Regulatory Posture conditional | For providers in a regulated industry ONLY: does the API publish the consent, security, legal, and standards-conformance posture its regime demands? Consent-... | 15% |
| Open Source Surface conditional | For providers whose product is itself open source ONLY: does the repository publish the maintainership surface a consumer needs in order to depend on it? A v... | 10% |
Agent readiness separate score
A standalone 0–100 score measuring how safely an autonomous agent can drive the API, mapped to its own 4 bands. A provider can be Thin for humans yet Agent-Ready, or Strong yet Human-Only.
| Agent-Native | 38.7+ 1.1% | Built to be driven by agents, and the provider built it — a contract, a real agent surface the provider itself publishes, and the safety rails the band gate now requires: idempotency AND a stable error envelope. The providers an agent can drive safely today, as opposed to the providers somebody has written agent artifacts about. |
| Agent-Ready | 28.6 – 38.6 9.6% | An agent can drive the core surface. A machine-readable contract and documented auth are in place, and there is real agent-facing work beyond the baseline; the safety rails (idempotency, stable errors, rate-limit signalling) mostly are not.NARROWED IN 0.6. This band used to hold the enrichment baseline plateau — ~3,300 providers whose agentic-access contract was generated for them. Once that credit was graded down the plateau fell to 30–32 and the cut moved above it, so this band now means an agent surface the provider had a hand in rather than one the catalog supplied. |
| Agent-Aware | 5.1 – 28.5 26.1% | Partial machine-readable surface. An agent can read some of the API but would hit implicit conventions a human silently absorbs — the gaps where it retries blindly or gets stuck. |
| Human-Only | 0 – 5 63.1% | Little an agent can consume without a human first reading the site. A developer can integrate it; their agent cannot yet. |
19 dimensions feed the score (points each):
Transparency is the product
The rubric is versioned, all 111 checks are enumerated with the points they award, and the bands are calibrated against the real distribution of what is actually out there rather than picked to flatter anyone. If you disagree with a weight, you can see the weight. If you think a check is wrong, you can see the check. A rating nobody can inspect is just an opinion with better production values, and the industry has enough of those.
Where it runs
The rating system is licensable, and APIs.io is the first company to license it. It runs across the entire APIs.io catalog on every rebuild, shows up in search results and on every provider's page, and is served through the APIs.io API and MCP server so both people and their agents can filter and rank by it.
See it running on APIs.io
Browse live ratings for thousands of API providers, and read the full rubric — every facet, all 111 checks, both scoring axes, and the agent-readiness dimensions with their exact points.
The full rubric & live ratings at APIs.io →How a provider improves
Every provider is profiled from a public repository in the API Evangelist GitHub organization — github.com/api-evangelist/<provider>. That is where the scored artifacts live, so improving a rating is a normal open-source contribution:
- Ask a question — open an issue on the provider's repository.
- Add an artifact — submit a pull request with the missing spec, plans, rate limits, or agentic-access contract; the next scoring run picks it up.
- Have it done for you — prioritized profiling for $2,500: I audit your surface, add the artifacts, and move you up the queue.
The first two paths are free and always will be — the rubric is open specifically so any provider can climb it on their own.
Related reading
Run a catalog, marketplace, gateway, or procurement process and want to score API surfaces on a rubric that is open, agent-aware, and not for sale to the highest bidder? The system exists, it is proven, and you can license it too — get in touch.
Newsletters
Two emails, both Monday mornings. Take either, or both.
API Evangelist
Highlights of the stories, conversations, and API knowledge published across the industry each week.
The Specification Layer
What actually merged into the thirty specifications the Linux Foundation stewards — OpenAPI, AsyncAPI, JSON Schema, and the rest.
Discover APIs
Search across thousands of APIs on apis.io →