01 / Reference · endpoint coverage

API Coverage

Every endpoint and GraphQL entity your client calls, mapped against what the sandbox returns. Rows marked served are answering with real universe data and were checked against the official provider specs by the conformance suite on this build — statuses are synced from test results, never hand-set. Everything else answers with an explicit coverage error, never invented data.

This page compares the 25 providers. The full endpoint table for one provider — every row the manifest carries, deferred long tail included, nothing capped — is on that provider's own page: click its name below.

Served & verified

3,026

Read surfaces answering with real universe data across 25 hosts, every response checked against the vendor's published spec.

The full read API

4,524

Every read endpoint, GraphQL entity and git-transport route these providers publish, long tail included, minus the rows excluded by policy. Writes are out of scope: this sandbox is read-only.

Separately, 6 writes are accepted into a per-key 24-hour scratch layer — visible only to the key that wrote them, gone in a day, and never counted in the number above. How scratch writes work.

Not served yet

1,459

Each returns an explicit coverage error, never invented data. A further 39 rows were retired by the provider itself and are served only on snapshots pinned before that date.

Across the whole fleet, 4,330 of the 4,524 read rows have reached a final answer — Deep, 96%. That counts more than “served & verified”: it adds the rows whose final answer is a reviewed empty, a documented refusal, or an endpoint the provider retired upstream. The two numbers answer different questions, and the column headings below say which is which.

02 / The fleet

How the providers compare.

2 of 25 providers

Every provider SandboxAPIs replicates, with the coverage the manifest publishes for it on this build. The provider name opens its full endpoint table.
Provider, sorted descending; activate to reverse	Category, activate to sort by this column	Coverage, activate to sort by this column	Final answers, activate to sort by this column	Served & verified, activate to sort by this column	Core, activate to sort by this column	Protocols	Pins, activate to sort by this column	Spec source	Writes, activate to sort by this column
CircleCIcircleci.sandboxapis.dev	CI/CD	Full 100%	61/61	60	22/22	REST	5	Vendor spec	50
Buildkitebuildkite.sandboxapis.dev	CI/CD	Deep 99%	77/78	47	18/19	REST	5	Hand-authored	91

Show all 25 providers

Looking for one endpoint?

Every row the manifest carries for a provider — the deferred long tail included, nothing capped — is on that provider's page, grouped by family and filterable by path. To search paths across all providers at once, the catalog's search does it. The plan of record is the coverage manifest itself, served byte-for-byte as this build read it.

Request 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 taken before that date keep serving it, exactly as they did — which is what pinning is for. We check every vendor's published spec for this once a week, and each week's findings are in the API drift report.
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,322 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 (4,794 across the 25 providers — largest are 1,043 Datadog, 996 GitLab, 588 GitHub, and 20 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.)