github/repo — one repository, with the source field names kept

The call

Parameters (1)

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

⚠️ `watchers_count` IS NOT WATCHERS. IT IS STARS, AGAIN. Measured on `vercel/next.js` on 4 October 2026: `stargazers_count` 143,169 and `watchers_count` 143,169 — the same integer, because the GitHub API returns stars in both. The real watcher count lives in `subscribers_count`, which was 1,632 on the same read. That is a factor of 87. A dashboard that labels `watchers_count` as 'watching' is off by two orders of magnitude and will never notice, because the number is plausible and moves.

WE DO NOT RETURN `subscribers_count`, and we are telling you rather than quietly substituting it. Renaming `watchers_count` to `stars` would be kinder and would also create a second vocabulary for the same upstream field — the thing this API exists to avoid. The field keeps its source name and this page carries the warning.

THE FIELD NAMES ARE THE GITHUB ONES THROUGHOUT: `stargazers_count`, `forks_count`, `open_issues_count`, `language`, `topics`, `archived`, `fork`. A repository is not a post and a star is not a like, so none of them is folded into the `metrics` vocabulary the social routes share. Asking for a repository and getting `likes` would be a worse answer.

⚠️ A RENAMED REPOSITORY ANSWERS 200 UNDER ITS NEW NAME, and the `fetch` follows that redirect without saying so — asking for `owner/old` would hand you `owner/new` with a 200. We compare `full_name` against what you asked and return 404 when they differ. You get an honest 'that name does not exist' instead of a silent substitution.

`full_name` is also the anchor that decides whether the document is a repository at all. The earlier anchor was 'a JSON object with no `message` key', and a probe of `{"documento":"legivel"}` passed it as found — a well-formed object with no repository fields would have been served as a valid answer with every field null.

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".