Point a Sentry API client at https://sentry.sandboxapis.dev — paths are /api/0/…, exactly like sentry.io. sentry-cli takes --url (or SENTRY_URL); the official sentry-mcp server takes --host / SENTRY_HOST. Auth is a Bearer token (any value is accepted here). This is the org's ERROR TRACKING surface: projects are the services the org deploys, issues are deduplicated error signatures, and an event's stack frames name REAL files at REAL commit shas — take a frame's filename and lineNo here and fetch the same file at the same sha from the git host, and the source lines match. The incident the trackers and chat hosts discuss is the same incident firing here.
Coverage badge
Deep78/86 · 91%
The share of read rows with a final answer — served and verified, a deviation, retired upstream, or a reviewed empty/refusal. Computed in the coverage manifest, copied here.
sentry.sandboxapis.devServed & verified
63 / 73%
Answering with real universe data, each response checked against Sentry's published spec by the conformance suite on this build.
The full read API
86
Every read surface Sentry publishes, deferred long tail included, minus the rows excluded by policy. Writes are out of scope: this universe is read-only.
Not served yet
23
Each returns an explicit, provider-shaped coverage error naming the gap — never invented data.
01 / The swap
No SDK of ours, no shim, no recorded fixtures. The same client library you already use, one environment variable different.
curl -H 'Authorization: Bearer anything' "https://sentry.sandboxapis.dev/api/0/organizations/olympus-labs/projects/"Verified drop-in clients
No client library is version-pinned against Sentry yet, so this page claims none. What is asserted is the wire: every response above is validated against Sentry's own published spec by the conformance suite. Client pins live in coverage/client-pins.yaml and are added as each SDK joins the suite.
02 / Coverage by family
All 86 rows the coverage manifest carries for Sentry, deferred long tail included and nothing capped. Open a family, or filter by path to find the exact endpoint your client calls.
Status — what a conformance test found
Mode — what kind of answer a row gets
A row with no mode shown has not been judged yet. Modes are the manifest's own words, from coverage/MODES.yaml; every empty and refuse carries a written reason and a review date before it counts as final.
Badge — where Deep starts
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.
86 read surfaces in 13 families
no debug information file is uploaded by any project here - every project is the `node` platform (render.ts:161) and a Node project produces no dSYM or PDB to upload; Sentry's own answer for a project with none is `[]` at 200; RULED by the founder 2026-09-12
no service hook is registered on any project in this universe - canon's webhook_subscription rows are the incident-alerting subscriptions (filter_kind account/service/team, delivery_url hooks.olympus-labs.dev) and, from hello-18's webhookFilters, the repository, organization and namespace hooks a repository host publishes - and no row of either kind is a Sentry project hook (clause re-worded at the hello-18 cutover 2026-09-12: the canon grew, the conclusion did not move); Sentry's own answer for a project with none is `[]` at 200; RULED by the founder 2026-09-12
SERVED 2026-09-12: `raw` is the repository's own .github/CODEOWNERS, byte for byte out of the tree, and schema.rules is that text parsed - every principal in it is a team /organizations/{org}/teams/ serves (invariant #5). The four required settings are stated judgments: isActive and codeownersAutoSync are facts about the FILE (it exists and is re-read from the tree on every request), while fallthrough=false and autoAssignment=`Turn off Auto-Assignment` are absences of SENTRY-side configuration - the second corroborated by shapeIssue's assignedTo, which is the incident commander and never an owner. Generation-gated on features.repoOwnership (hello-17)
SERVED 2026-09-12: the response is an array of [timestamp, count] pairs with no required object field, and the counts are real buckets over error_event.t_epoch for the service the project IS. The default grid is the 24 hourly buckets the vendored example carries, ending at the artifact's ANCHOR; `rejected` and `blacklisted` are zero everywhere because this universe records no rejected ingest
no custom symbol source is configured on any project here - canon carries no symbol server and every project is the `node` platform, which has no native symbols to fetch; Sentry's own answer for a project with none is `[]` at 200; RULED by the founder 2026-09-12
SERVED 2026-09-12: required `name` only - the project-scoped de-duplication of the same per-event tag list the issue-scoped twin aggregates
nobody has submitted user feedback in this universe - the served project object says so (SURFACE_FLAGS.hasFeedbacks=false and hasNewFeedbacks=false, render.ts:166) and canon's error events are SDK-reported with no attached report; Sentry's own answer for a project with none is `[]` at 200; RULED by the founder 2026-09-12
SERVED 2026-09-12: required username+email only, and eventUser() already shapes exactly those two fields from error_event.person. An event the canon recorded no person for contributes nobody rather than a row of nulls, and every address joins to a canonical person under the org-wide convention every provider in the fleet shares
refuse — ENTAILED by the empty beside it: .../hooks/ serves `[]` on this same host, so no hook id can name a service hook and Sentry's own 404 is the whole answer; RULED by the founder 2026-09-12
generate — NEW CANON ENTITY SentryProjectKey, and NOT a widening: no client key, public key, secret, ingest host or DSN exists in any table or any generation, and person_credential's nine kinds are PEOPLE'S keys - ssh, gpg, email, social, personal, project, group and deploy tokens - rather than a project's ingest key. The blocker is the opposite way round from this provider's other tier-1 gap: the schema is complete (component ProjectKey) and it is the canon that is absent. `dsn` is REQUIRED with all nine sub-fields required non-nullable strings (cdn, crons, csp, minidump, nel, public, secret, security, unreal), so nothing here can be honestly nulled and no field may be omitted. The render-time minting precedent exists - PagerDuty's derivedRoutingKey, CircleCI's masked tail - but is strictly smaller than nine DSN URLs carrying a user:password@host shape, which is why the answer is a table rather than a mint, and the standing credentials ruling is that canon holds a public half whose private half was never generated. Priced at ~11 KB by the 2026-09-12 W1 wave. It unblocks TWO rows, both TIER 1, both on this provider. CLASSIFIED 2026-09-13 (the unjudged-47 pass) on the 2026-09-12 sweep's proposal
generate — one client key by id, blocked by the same absent SentryProjectKey table as the list beside it; the same ~11 KB entity unblocks both. CLASSIFIED 2026-09-13 (the unjudged-47 pass)
SERVED 2026-09-12: the ORG-scoped twin of /projects/{org}/{proj}/events/{event_id}/, which has been `derive` since 2026-09-01. Every required field (event/eventId/groupId/organizationSlug/projectSlug) is the same lookup without the project scope, and the embedded event is byte-identical to the project-scoped read of the same id
SERVED 2026-09-12 (the unclassified sweep): the roster's own row, by the id the roster publishes. The operation's 200 IS the component OrganizationMemberWithRoles, which is the list item plus six required fields, and every one of them was already a fact this host holds - `teams` and `teamRoles` are reader.teamMembers(), the same edge /teams/{org}/{team}/members/ has paged since M2 and which the suite now walks in BOTH directions; `isOnlyOwner` is computed off the roster rather than asserted (nobody holds `owner`, so nobody is the only one who does, and the day canon grows an owner the answer moves); `invite_link` is null, the same fact the green list row states as `inviterName: null`. The two ROLE CATALOGS are the only values here that are not an artifact row: they are Sentry's own vocabulary, copied verbatim out of the vendored description's worked example (openapi-derefed.json, the UpdateAnOrganization example), and the conformance case reads that example back out of the document and reds the row if the served bytes differ by so much as a scope string - so the copy is evidence rather than invention and cannot rot. teamRoles[].role is the catalog's own `minimumTeamRole` for the org role the member holds, looked up rather than chosen, because canon assigns nobody an explicit team role and the schema types `role` as a required non-nullable string
no Sentry Relay is deployed in this organization - every error event is recorded directly against a project (error_event.service, 85 rows) and canon carries no relay entity at all; Sentry's own answer for an organization with no registered relay is `[]` at 200; RULED by the founder 2026-09-12
SERVED 2026-09-12: required id/message/dateCreated IS the object shapeReleaseCommit already returns for /releases/{version}/commits/, over reader.listCommits(repo) rather than one release's range. The {repo_id} resolves against the ids /organizations/{org}/repos/ already publishes
SERVED 2026-09-12: every canonical error_event is one accepted `error` outcome at a real instant, so the series is a bucket count over error_event.t_epoch grouped by project/category/outcome. The window ends at the artifact's ANCHOR, never at a wall clock (invariant #1), and a caller who names no period gets the artifact's own window - the only default this host can claim provenance for. A category or outcome this universe never ingested selects nothing
SERVED 2026-09-12: the same bucket count over error_event.t_epoch, rolled up per project rather than per interval. The five drop columns (filtered, rate_limited, invalid, abuse, client_discard, cardinality_limited) are zero because this universe records no rejected ingest at all - there is no ingest, the events were generated - and saying so is what stops a caller reading a drop rate off a number nothing supports
no release threshold is configured on any project in this universe - canon's Release (3) carries a tag, a commit, an author and a body and no threshold rule; Sentry's own answer for an organization with none is an empty object at 200; RULED by the founder 2026-09-12
no release in this universe uploads release artifacts - every project is the `node` platform (render.ts:161, read off the file model) deployed from the git repository, and nothing here runs `sentry-cli releases files upload`; Sentry's own answer for a release with no files is `[]` at 200; RULED by the founder 2026-09-12
no SDK in this universe reports release-health sessions - the served project object already says so (SURFACE_FLAGS.hasSessions=false, render.ts:166) and canon carries no session counter; Sentry's own answer for an organization with no session data is a 200 whose `groups` is `[]` over real intervals; RULED by the founder 2026-09-12
SERVED 2026-09-12: the project-scoped twin of /organizations/{org}/releases/{version}/commits/, which has been `derive` since 2026-09-01 - same rows, same shaper, narrower scope (the release must be one this project ships)
the project-scoped half of the same fact: no release in this universe uploads release artifacts (every project is `node`, deployed from git, and nothing runs `sentry-cli releases files upload`); Sentry's own answer is `[]` at 200; RULED by the founder 2026-09-12
refuse — ENTAILED by the empty beside it: .../releases/{version}/files/ serves `[]` on this same host, so no file id can name a release artifact and Sentry's own 404 for this operation is the whole answer (the agents/{id} precedent, MODES.yaml 2026-09-06); RULED by the founder 2026-09-12
refuse — ENTAILED by the empty beside it: the project-scoped file list serves `[]`, so no file id resolves and Sentry's own 404 is the whole answer; RULED by the founder 2026-09-12
SERVED 2026-09-12: a grouping hash is a digest of the SIGNATURE events were grouped on, and canon's signature is the pair the generator deduplicated by (the exception type and the culprit path) - so a canonical ErrorGroup has exactly one hash, derived by ids.ts's existing hex derivation. `latestEvent` is the group's newest shaped event, the same one events/latest/ serves
SERVED 2026-09-12: eventTags() already computes the whole tag vocabulary per event from canon (level, server_name, environment, release), so `totalValues` is a count over the group's own events. A key no event of the group carries is Sentry's own 404 - a tag key exists because events have it
SERVED 2026-09-12: the same per-event tag list eventTags() computes, de-duplicated over the group's events and sorted. No field outside eventTags is required
no event in this universe has a minified frame to unminify - the served project object says so (SURFACE_FLAGS.hasMinifiedStackTrace=false, render.ts:166) and every error_frame (51) resolves to a real file in the repository tree at the group's resolved_sha, with the real source lines served as the frame's `context`; Sentry's own answer when it finds no problem is `{errors: []}` at 200; RULED by the founder 2026-09-12
Session Replay is not enabled for any project in this universe - the served project object says so (SURFACE_FLAGS.hasReplays=false, render.ts:166) and canon carries no replay, click or recording-segment row; Sentry's own answer for a count query with no replays is an object of zeros at 200; RULED by the founder 2026-09-12
the same fact: no replay exists, so no DOM selector was ever recorded (SURFACE_FLAGS.hasReplays=false); Sentry's own answer is `{data: []}` at 200; RULED by the founder 2026-09-12
no replay exists in this universe - the served project object already asserts hasReplays=false (render.ts:166) and no canonical entity records a session recording; Sentry's own answer for an organization with none is `[]` at 200; RULED by the founder 2026-09-12
refuse — ENTAILED by the empty beside it: .../replays/ serves `[]`, so no replay id resolves and Sentry's own 404 is the whole answer; RULED by the founder 2026-09-12
refuse — ENTAILED by the replay empty: no replay id resolves on this host, so Sentry's own 404 is the whole answer; RULED by the founder 2026-09-12
refuse — ENTAILED by the replay empty: no replay id resolves, so there is no recording to segment; RULED by the founder 2026-09-12
refuse — ENTAILED by the replay empty: neither the replay id nor a segment index inside it resolves; RULED by the founder 2026-09-12
refuse — ENTAILED by the replay empty: no replay id resolves, so nobody can have viewed one; RULED by the founder 2026-09-12
no issue-alert rule was ever created on any project here - canon's `monitor` is a METRIC threshold (series, comparison, threshold, for_sec) and not an issue rule, and every required field of Sentry's `Rule` but `id` and `projects` is configuration this universe never made: `conditions`, `filters` and `actions` carry Sentry's own internal class paths; Sentry's own answer for a project with none is `[]` at 200. RULED by the founder 2026-09-12 on the unclassified sweep's proposal, as proposed.
generate — A WIDENING, NOT A BUILD: canon's `monitor` table is very nearly a Sentry metric alert rule already (packages/artifact/src/rows.ts:548) - id, name, created_epoch (dateCreated), for_sec (timeWindow), comparison (thresholdType), threshold (triggers[].alertThreshold) and service -> projects all map, reader.listMonitors() serves the rows today, and an activation maps field-for-field onto AlertRow (fired_epoch, resolved_epoch, peak_value, state). WHAT IS MISSING IS AN AUTHOR: MonitorRow has no `created_by`, `createdBy` is REQUIRED on Sentry's AlertRule schema, and no other canonical fact answers who wrote a threshold - so a rule cannot be shaped without inventing one. The widening is ONE nullable person column on `monitor`, written at generation time from the owning service's team lead, and the same wave owes a ruling on the three other required fields whose values are Sentry's own vocabulary rather than this universe's data (`query`, `aggregate`, `monitorType`). It unblocks THREE rows, all on this provider - this list, the by-id read and the activations list - and none elsewhere: nothing else in the fleet reads a monitor's author. CLASSIFIED 2026-09-13 (the unjudged-47 pass) on the 2026-09-12 sweep's proposal, which analysed it and left it unclassified
generate — the same rule by id, blocked by the same required `createdBy` the list is - one nullable author column on canon's `monitor`. An id naming no monitor stays Sentry's ordinary 404 either way. CLASSIFIED 2026-09-13 (the unjudged-47 pass)
generate — the activations of one rule. THE ACTIVATION ROWS THEMSELVES ARE ALREADY CANON - AlertRow carries fired_epoch, resolved_epoch, state and peak_value, which is what dateCreated / finishedAt / isComplete / metricValue want - so this row is blocked only because it hangs off a rule that cannot be shaped: the parent must resolve before its children can, and the parent needs the author column. The SAME one-column widening on `monitor` unblocks it. CLASSIFIED 2026-09-13 (the unjudged-47 pass)
refuse — ENTAILED by the empty beside it: the project's rule list serves `[]` on this same host, so no rule id resolves and Sentry's own 404 is the whole answer. RULED by the founder 2026-09-12 on the unclassified sweep's proposal, as proposed.
SERVED 2026-09-12: the same [timestamp, count] array as the project stats, summed over the services the team owns (service.team) - the set /teams/{org}/{team}/projects/ already resolves
no cron monitor is configured in this Sentry organization - the served project object says so (SURFACE_FLAGS.hasMonitors=false, render.ts:166); canon's `monitor` table (14) is a METRIC threshold monitor (series/comparison/threshold/for_sec) with no schedule, and the one scheduled job in the universe (workflow_schedule, a nightly on repo-01) belongs to no service and so has no Sentry project to be monitored in; Sentry's own answer for an organization with none is `[]` at 200; RULED by the founder 2026-09-12
refuse — ENTAILED by the empty beside it: .../monitors/ serves `[]` on this same host, so no id or slug can name a cron monitor and Sentry's own 404 is the whole answer; RULED by the founder 2026-09-12
refuse — ENTAILED by the same empty: with no cron monitor, no monitor id resolves and there is nothing to check in against; RULED by the founder 2026-09-12
refuse — the project-scoped route to the same non-existent monitor; entailed by the org-scoped `[]`; RULED by the founder 2026-09-12
refuse — the project-scoped route to the same non-existent monitor's check-ins; entailed by the org-scoped `[]`; RULED by the founder 2026-09-12
SERVED 2026-09-12: the `SCIM is not enabled, so 403` reading is FALSIFIED by the artifact - identity_provider_config carries protocol=saml with scim_enabled=1 from hello-15 on. A SCIM Group IS a Sentry team (the sibling path parameter is literally {team_id}) and `displayName` is the team SLUG, which is what the vendored example's own slug-shaped value carries. Generation-gated: an artifact predating features.ciConfig names hello-15 rather than serving an empty directory
SERVED 2026-09-12: one group by the same team id /organizations/{org}/teams/ already serves; displayName is the team slug and members are the real team members. Generation-gated on features.ciConfig (hello-15), like the list beside it
SERVED 2026-09-12: a SCIM User is an org member addressed by the MEMBER id the path parameter names, which /organizations/{org}/members/ has served as a `derive` row since 2026-09-01. `sentryOrgRole` is orgRoleFor(), the one mapping this renderer already makes, so the directory and the member list cannot disagree. Generation-gated on features.ciConfig (hello-15)
SERVED 2026-09-12: the same resource by member id. `name` splits the canonical name on its first space; a persona with one name has an EMPTY familyName, which is the absence expressed in the field's own type rather than Sentry's own `N/A` placeholder (invariant #4). Generation-gated on features.ciConfig (hello-15)
nobody in this organization has saved a Discover query - canon's saved queries are the Zendesk ticket views in saved_search (record_kind=ticket, owned by crm-user rows) and, from hello-18's savedFilters, the Jira-shaped rows in saved_filter - and neither table carries a Sentry-scoped Discover query (clause re-worded at the hello-18 cutover 2026-09-12: the canon grew, the conclusion did not move); Sentry's own answer for an organization with none is `[]` at 200; RULED by the founder 2026-09-12
SERVED 2026-09-12: Discover over the real event store (error_event, every row a real error at a real instant). The covered field set is closed and named - id, issue, issue.id, project, project.name, title, timestamp, level, release, environment, server_name, the three user columns, and count() as the one aggregate - and a field outside it answers an explicit 400 with the coverage pointer rather than a silent null (invariant #4). Sentry's structured search grammar is not parsed, so a non-empty `query` is refused rather than ignored
refuse — ENTAILED by the empty beside it: the saved-query list serves `[]`, so no query id resolves and Sentry's own 404 is the whole answer; RULED by the founder 2026-09-12
nobody in this organization has built a dashboard - verbatim the fact `/discover/saved/` beside it was already ruled on, one entity further on: there is no Dashboard row and no widget row anywhere in the artifact, and listStatusDashboards() is a Statuspage entity in a different domain; Sentry's own answer for an organization with none is `[]` at 200. RULED by the founder 2026-09-12 on the unclassified sweep's proposal, as proposed.
refuse — ENTAILED by the empty beside it: the dashboard list serves `[]` on this same host, so no dashboard id resolves and Sentry's own 404 is the whole answer. RULED by the founder 2026-09-12 on the unclassified sweep's proposal, as proposed.
verbatim the fact `sentry-app-installations/` was already ruled on, at the other of the two addresses Sentry publishes it from: canon carries no app or integration install row of ANY kind, and integrationsFor() is PagerDuty's inbound alert route over a deliberately fictional vendor catalogue - a different provider's entity in a different domain; Sentry's own answer for an organization with none installed is `[]` at 200. RULED by the founder 2026-09-12 on the unclassified sweep's proposal, as proposed.
no Sentry app is installed in this organization - canon carries no app or integration install row of any kind and this replica serves no /sentry-apps/ surface for one to be installed from; Sentry's own answer for an organization with none is `[]` at 200; RULED by the founder 2026-09-12
03 / What's simulated
Each line below is one assertion in the conformance suite named beside it — run on every build, over one artifact, through the real renderers. Nothing is claimed here that no expect checks.
The sha an error group's stack frames resolve against is a commit the GitHub host serves, and the source lines shipped in each frame's `context` are the bytes GitHub returns for that file at that sha — same path, same line numbers, same text.
Against GitHub · parity/incident-parity.test.ts
The pull request whose merge flips an issue here to `resolved` is merged on the GitHub host at that same merge-commit sha, on the branch the git canon named.
Against GitHub · parity/incident-parity.test.ts
The issue assigned here and the incident PagerDuty paged for name the same person and the same service; PagerDuty's trigger entry is at or before this host's `lastSeen`, and its resolve entry is after the fix commit.
Against PagerDuty · parity/incident-parity.test.ts
05 / Pinned snapshots
Each pin regenerates byte-identically on every request, so a test written against one never drifts. Generations are DIFFERENT universes, not versions of one — never swap a suffix expecting the same data.
sentry-v0.snap.sandboxapis.devgeneration 7v0servedsentry-v0-g10.snap.sandboxapis.devgeneration 10v0servedsentry-v0-g11.snap.sandboxapis.devgeneration 11v0servedsentry-v0-g8.snap.sandboxapis.devgeneration 8v0servedsentry-v0-g9.snap.sandboxapis.devgeneration 9v0servedNeed an endpoint that is not served yet?
Every row Sentry's manifest carries is on this page, so “not here” is an answer rather than a gap in the rendering. Tell us which path and which client, and it moves up the queue — the order is set by what people ask for.