Documentation 29
Sentry API quickstart · 3 min read
Stack traces that point at real files.
A Sentry-compatible error-tracking API for a simulated org — projects, issues, events, teams and releases. Every stack frame names a path that exists in a repository you can browse, and carries that file's own source lines as its context rather than invented filler; the release the error arrived on hands you the real commits behind it. The outage these errors describe is the same outage the trackers, the chat host and the git hosts are talking about.
Coverage, hosts and pinned snapshots for Sentry — 63 of 86 read surfaces served and verified.
01 / Base URL + auth
One origin, any token.
Requests go to https://sentry.sandboxapis.dev. Paths are Sentry's own — /api/0/…, trailing slashes included, exactly as sentry.io serves them — and the region lives in the hostname, never in a path segment, so a client that already builds https://us.sentry.io only changes the host it was already building. Auth is a Bearer token; any value passes here, so there is no organization to create and no auth token to mint.
curl -H 'Authorization: Bearer anything' \
"https://sentry.sandboxapis.dev/api/0/organizations/olympus-labs/projects/"Using a key? Keys & rate limits → — a SandboxAPIs key rides the same Bearer slot and lifts the anonymous limit.
02 / What this host serves
Errors with a paper trail.
A Sentry project here is a service the simulated org actually deploys, owned by a team whose members are real people on the other hosts. A Sentry issue is a deduplicated error signature; its assignedTo is the engineer who was paged for the incident, and its status flips to resolved at the commit that fixed it — not before, and not on a schedule.
# the project's unresolved issues (Sentry's implied is:unresolved default)
curl -H 'Authorization: Bearer anything' \
"https://sentry.sandboxapis.dev/api/0/projects/olympus-labs/<project>/issues/"
# the newest event on one of them, with its full stack trace
curl -H 'Authorization: Bearer anything' \
"https://sentry.sandboxapis.dev/api/0/organizations/olympus-labs/issues/<issue_id>/events/latest/"The frames in that response carry filename, lineNo and a context array lifted out of the real file — not text written to look like source. Take the filename to the GitHub host and you are browsing the same file the trace names, which is the thing a fixture library cannot do. Sentry's event shape carries no commit sha on a frame, so neither does ours; the shas live where Sentry puts them, on the release's /commits/ endpoint. See what's covered →
03 / Pagination
Follow rel=next; never parse a cursor.
List endpoints paginate through the Link header, in Sentry's own grammar: both rel="previous" and rel="next" are always present, and results="true|false" tells you whether the page they name has anything in it. Follow the URL verbatim and your client never has to understand the <id>:<offset>:<is_prev> cursor at all.
Link: <https://sentry.sandboxapis.dev/api/0/organizations/olympus-labs/members/?&cursor=0:0:1>; rel="previous"; results="false"; cursor="0:0:1", <https://sentry.sandboxapis.dev/api/0/organizations/olympus-labs/members/?&cursor=0:100:0>; rel="next"; results="true"; cursor="0:100:0"04 / Read-only + coverage
Every refusal is Sentry-shaped.
This universe never changes. A write returns Sentry's own error envelope — 403 {"detail": …} — naming what you tried and where the roadmap is. A path outside coverage returns the same envelope at 404 with an x-sandboxapis-coverage header pointing at the manifest, and a query we don't answer (Sentry's structured search syntax, full=true, release-health roll-ups) returns an explicit 400 rather than an unfiltered list that would read like an answer.
05 / Pin for CI
A frozen universe, by hostname.
Point CI at https://sentry-v0.snap.sandboxapis.dev and the bytes stop moving: same issues, same event ids, same shas, run after run. The live host tracks the newest universe; a pin never does.
export SENTRY_URL="https://sentry-v0.snap.sandboxapis.dev"