API Coverage

03 / How to read this

What the numbers mean.

• Served & verified — the endpoint answers with real universe data, and the conformance suite checked that response against the provider's published spec on this build. Statuses come from those test results; they are never hand-set to green. A row marked deviation is served and matches the real provider, but does not validate against the vendored spec — usually a bug in the spec itself. Those are counted separately, never as verified.
• Final answers — the badge's numerator, and a wider count than served: it adds the rows whose answer is finished without being a served payload — a reviewed empty, a documented refusal, or an endpoint the provider retired upstream. A provider reads at or above its served bar, and only Full means there is nothing left to answer. The badge word in the Coverage column is that ratio, cut at thresholds the manifest owns and this page copies — see the catalog legend for the ladder.
• Retired — the provider removed this endpoint from its own API, so our live host stopped serving it on the same day; calling it returns the provider's error shape naming the date and where it still works. The pinned snapshots frozen before that date keep serving it, exactly as they did — which is what pinning is for.
• The full read API — every read endpoint the provider documents, plus its GraphQL entities and git-transport routes where it has them, long tail included. Percentages on this page divide by that number and nothing else, so partial coverage never gets rounded up against a friendlier denominator. REST + GraphQL + git rows that are not `excluded`. Write operations are NOT rows (DECISIONS 2026-09-01 decision 9): they are counted in meta.write_operations and never enter this ratio.
• Not served yet — an explicit coverage error, never invented data: REST answers 404 with an X-SandboxAPIs-Coverage header, GraphQL returns an entry in errors rather than a silent null. Both name the gap and point back here. That is what makes partial coverage safe to build against: your integration fails loudly rather than passing on fiction.
• Core — the manifest's tier-1 slice: the endpoints nearly every integration actually calls, and what we serve first. It answers the question a percentage cannot — is the covered slice the useful slice? The 1,179 rows still deferred are the long tail, and every one of them is listed on its provider's page rather than reported as a bare count: this page used to withhold that tail, which left it answerable only by downloading the coverage manifest and grepping it.
• Spec source — what we validate a provider's responses against. Most are the vendor's own machine-readable description. Hand-authored is the weaker guarantee, stated rather than implied: the vendor publishes no such document, so ours is written from their docs plus live captures and re-diffed on a schedule.
• Write operations are excluded by policy (3,526 across the 21 providers — largest are 996 GitLab, 582 GitHub, 393 Jira, and 16 more providers, plus every Linear mutation). A write returns the provider's error shape naming the attempt and a roadmap link. (Cursor's three POST-as-read usage endpoints are reads in the provider's own grammar and are counted as coverage above, not here.)