CI roll-up for a page of pull requests

GET/api/repos/{owner}/{repo}/pulls/checks

listPullRequestChecksRollup

Returns one check roll-up per PR for the same page the sibling list endpoint returns, in the same order. Two statements for the whole page regardless of page size. Each roll-up is the newest-run-per-context collapse over that PR's CURRENT head — the same set the PR's own checks endpoint and the merge gate judge, so a list row can never contradict the PR it links to. Separate from the list payload on purpose: check state churns while a run is in flight and the rest of a PR row does not, so the two carry different cache lifetimes.

Authentication is not described for this operation in the spec — that does not mean it is public. Check tokens and scopes.

curl

curl -X GET 'https://neosource.dev/api/repos/OWNER/REPO/pulls/checks'

fetch

fetch("https://neosource.dev/api/repos/OWNER/REPO/pulls/checks", {
  method: "GET",
});

Path parameters

ownerrequired: Repository owner or organization slug.
string
reporequired: Repository name.
string

Query parameters

status: Filter by status.
PullRequestStatus
string
Lifecycle status of a pull request.
"open""merged""closed"
limit: Maximum number of results.
integerint64
default30
offset: Offset for pagination.
integerint64
default0

Responses

200Per-PR check roll-ups

application/json

PullRequestChecksListResponse

object

Roll-ups for one page of PRs, in the same order the sibling list returns them.

pull_requestsrequired

array

items

PullRequestChecksRollup

object

One PR's CI roll-up, keyed by its repo-scoped `number`. Deliberately NOT a field on [`PullRequestResponse`]. A PR's title, branches and author change when somebody edits them; its check state changes every few seconds while a run is in flight. Folding the second into the first would make every CI heartbeat invalidate the whole list payload — the client would refetch titles and branches to learn that a dot went green, and a prerendered snapshot would bake in a verdict that expires before anyone reads it. Two payloads, two cache postures.

checks_summaryrequired: ChecksSummary
head_commit: string | null
The head the roll-up was computed against (40-char Git OID hex), or `null` before the first push resolves one. Present so a client can tell "checked, nothing ran" from "there is nothing to check yet".
numberrequired: integerint32
Repo-scoped PR number — the join key back to the list payload.

Standard errors

Bodies documented once for the whole API — see standard errors.

400Bad Request — one of: invalid_input
403Forbidden — one of: forbidden
404Not Found — one of: not_found
423Locked — one of: busy
429Rate limited — retry after the `Retry-After` header
500Internal server error
503Service temporarily unavailable / at capacity — retry after the `Retry-After` header
504Gateway timeout — the request exceeded the server's handling budget

Schemas

Referenced above. Listed here rather than expanded inline, so the same definition is not repeated at every level.

`ChecksSummary`

object

Roll-up of the check states for the merge box. Counted over the newest-run-per-context set (`neosource_forge::head_checks`), so a run that a re-run superseded is not a second check.

failedrequired: integerint32
`failure` + `error` states — both render red and both block.
pendingrequired: integerint32
skipped: integerint32
Checks whose job never ran (gated off by a job-level `if:`, or a `needs:` predecessor did not succeed). Counted separately from `success`; `success + failed + pending + skipped == total`.
successrequired: integerint32
Checks that ran and passed. Deliberately EXCLUDES skipped ones: a skipped check carries `state: success` so it cannot block a merge, but counting it as "passed" would tell the reader that work happened when it did not — the same claim the per-check `skipped` flag exists to stop the UI making.
totalrequired: integerint32