How do I test a GitHub integration without a real organization?

You do not need one. Point your client at a read-only GitHub replica that already holds an organization, its repositories, pull requests, reviews and commits, and your code runs unchanged.

01 / The one change

Swap the base URL. Nothing else.

Your client talks to api.github.com. Point it at gh.sandboxapis.dev instead: same paths, same JSON, same headers, same status codes. No account, no token, no seed script. Any token is accepted.

For CI, use a pinned host. This page uses gh-2026-03-g12.snap.sandboxapis.dev, the pin the answer-key eval pack is verified on, which answers the same bytes on every run, so an assertion written today still holds next month.

The live host, gh.sandboxapis.dev, re-rolls daily and can carry a newer generation of the data set than gh-2026-03-g12.snap.sandboxapis.dev; every answer on this page is for gh-2026-03-g12.snap.sandboxapis.dev.

02 / Run it now

Read pull request 53.

request.sh

curl -s https://gh-2026-03-g12.snap.sandboxapis.dev/repos/olympus-labs/parthenon/pulls/53

It answers with title set to Fix the backfill job OOMing, opened by tiresias, with its head SHA, its branch and a merged state that the commits, reviews and the linked tracker issue all agree with. The same request from Octokit:

javascript

// npm install @octokit/rest@22.0.1
import { Octokit } from "@octokit/rest";

const octokit = new Octokit({ baseUrl: "https://gh-2026-03-g12.snap.sandboxapis.dev" });

const { data } = await octokit.pulls.get({ owner: "olympus-labs", repo: "parthenon", pull_number: 53 });
console.log(data.title, "by", data.user.login);   // Fix the backfill job OOMing by tiresias

03 / Writes

A write gets GitHub's own error shape.

Every host is read-only. A write answers 403 with GitHub's error body, naming what you tried, so your client's existing error handling meets a shape it knows:

403 · application/json

curl -s -X POST https://gh-2026-03-g12.snap.sandboxapis.dev/repos/olympus-labs/parthenon/issues -d '{"title":"test"}'

{"message":"This universe is read-only. See what's covered at https://sandboxapis.dev/coverage. (You tried to POST /repos/olympus-labs/parthenon/issues.) Tell us what you needed to write: https://sandboxapis.dev/feedback","documentation_url":"https://sandboxapis.dev/coverage","status":"403"}

A key with scratch writes turned on can create and comment on issues in a private overlay that only that key sees. Pull requests, branches and commits are never writable.

04 / Where it stops

Coverage is counted, not claimed.

475 of 667 GitHub read surfaces are served and verified against GitHub's own published spec. A call to one that is not covered returns a 404 with an X-SandboxAPIs-Coverage header, never invented data. The row-by-row list is on the GitHub reference and the coverage page.

Next: run the four-hop walk to watch one incident cross four services, or follow the GitHub agent tutorial for a script a CI job keeps.

What this is not

Read this before you rely on it.

SandboxAPIs is read-only: a write returns the provider's own error unless your key has opted in to scratch writes, and those never reach anybody else. Coverage is bounded, and the manifest that says exactly where it stops is public. The data is a simulated company, not yours and not a copy of anybody's. And it reproduces what each vendor documents and publishes, not the vendor's undocumented behaviour, so keep one test against the real service for that.