Copy page

GitHub

Twin of the GitHub REST API, over real git objects.

Twin of the GitHub REST API, backed by real git objects.

Covers	api.github.com, github.com, uploads.github.com
Auth	Personal access tokens (classic and fine-grained), OAuth App
Webhooks	Yes
Operations	268

Coverage

Repositories, contents, commits, branches, pull requests, issues, labels, releases, orgs, teams and webhooks. Blobs, trees, refs and commits are real git objects, so a commit you write is a real commit and a tree you read is a real tree.

Each host is served at the vendor’s own paths: the REST API on api.github.com, the OAuth App flows, web and device, on github.com, and release asset uploads on uploads.github.com. A release hands back an upload_url pointing at the twin, so a client that follows it lands in the sandbox.

Credentials

Any well-formed token authenticates by default. Both token kinds work, and fine-grained tokens carry the permissions your route needs. Set auth.mode to enforced to accept only tokens the world knows. See Credentials.

Vendor specific details

• A request with no User-Agent is refused with a 403 and an HTML body, before routing and before any credential check. Most HTTP clients set one. Bare curl and some minimal clients do not.
• The router beats the credential. An unknown path, a wrong method and a trailing slash all get the same anonymous 404 whether or not you sent a token.
• Owner and repository names match case-insensitively. Literal path segments do not.
• GitHub settles some fields after the create response returns. Default label colour, repository size and license detection all land a moment later, so a test asserting them immediately is asserting a race.

Its own notes

Once a sandbox is running, this twin serves its own operating notes at {control_url}/veris/manual: the credentials it accepts, the API versions it serves, and the fault statuses you can arm against it. They are generated from the same source as its behaviour, so they cannot drift.