Home · Docs · Endpoints · github/issue

github/issue — one issue, or one pull request, by number

A single issue by `owner/name` and `number`. The same API path serves pull requests, so the item says which you got — and `number` has no default on purpose.

The call

Path	`GET /api/v1/github/issue`
Catalogue id	`github/issue`
Cost	1 credit per call. A call that finds nothing costs nothing.
Key	Required — Authorization: Bearer hk_live_...

Parameters (2)

Name	In	Required
`repo`	query	yes
`number`	query	yes

That list is the whole list, and anything else is ignored in silence. An undeclared parameter is not rejected — it produces no error, no warning and no filtering. Check a parameter against this table before assuming a narrower result came back.

What the parameter list does not tell you

⚠️ YOU MAY HAVE ASKED FOR AN ISSUE AND RECEIVED A PULL REQUEST, and the measurement that proves it is the one we use as a fixture: we asked for number 9 of `vercel/next.js` and what came back was a PR — 'Added async props test', closed, `pull_request` present. We did not pick a PR to make a point; we picked a number and that is what the number was.

There is no issues-only endpoint upstream to ask instead, so the item carries `is_pull_request` and a `url` that reads `/pull/N` or `/issues/N`. Check one of them before assuming the kind.

⚠️ `number` IS REQUIRED AND HAS NO DEFAULT, and that is a decision rather than an omission. There is no such thing as a default issue. Defaulting to 1 would serve a real, wrong issue with a 200 — the failure mode that costs most, because nothing in the response says you did not ask for it.

`repo` takes the full `owner/name`, like every route in this family. The pair of a handle and a repo name as separate parameters was available and not chosen: one identifier means one thing to get wrong.

Why there is no success body on this page

The 200 body for this endpoint is not transcribed here. Reading it needs a client key, and there is no client key on the machine these pages were built from — internal keys exist only as hashes, by design. An example we never received would look exactly like one we did, so instead of composing one, the response shape is documented field by field on the schema pages below. Those are generated from the contract and tested against it in both directions; an invented example would be tested by nothing.

Response shapes (3)

PostsEnvelope — Every posts endpoint answers with this envelope. Eight fields, all required: you can read `success` and `credits_used` without checking whether they came.
Author — The normalised profile shape, identical across all platforms. All twelve fields are nullable, and that is the design: a field we cannot read comes back null, never 0, because a zero would be a claim about the account.
ApiError — Every 4xx and 5xx from the API carries this object. The `error` value is a stable string you can branch on; the extra fields appear only for the errors that have something to report.

Error codes (8)

Every one of them carries the same body shape: ApiError. The error value is a stable string you can branch on — branch on that, never on the message text.

400 · 401 · 402 · 404 · 405 · 451 · 503 · 502

Machine-readable

This endpoint is in /openapi.json (OpenAPI 3.1), with its cost on the operation itself. If you are generating a client, use the spec rather than this page — and note that the spec is filtered by what is switched on right now, so it is the better answer to "can I call this today".