GitHub · Pull requests · Reviews · Errors · Checked October 28, 2026

GitHub: a review request is refused

When you request reviewers for a pull request through the API, GitHub answers 422 Unprocessable Entity if the user is not a collaborator, and it can also answer 403 Forbidden (GitHub's REST API endpoints for review requests, checked October 28, 2026).

What GitHub answers

A request: POST /repos/{owner}/{repo}/pulls/{pull_number}/requested_reviewers takes reviewers (user logins) and team_reviewers (team slugs), and answers 201 Created, 403 Forbidden, 422 if the user is not a collaborator, or 503 Service unavailable.
A re-request: POST .../requested_reviewers/rerequest asks the same users or teams again, with the same 403 and 422 (rerequest reviewers).
Removing a request: DELETE .../requested_reviewers answers 422 when validation failed, or the endpoint has been spammed.
Too fast: requesting and re-requesting reviews triggers notifications, and creating content too quickly with these endpoints may result in secondary rate limiting (see API rate limit exceeded).

Who can request a review, and from whom

You: to request a review, you need write access to the repository. Pull request authors can request reviews only if they are repository owners or collaborators with write access, and organization members with write access or triage permissions can also assign a reviewer (GitHub's pull request reviews).
The reviewer: the pull request reviews page says you can request a review from a person or team with read access to the repository; the REST page says anyone with write access. Either way, a user who is not a collaborator is refused with 422.
A team: if you request a review from a team and code review assignment is enabled, specific members are requested and the team is removed as a reviewer (see a team review request reassigned).
After a review: once a requested reviewer submits a review, they are no longer a requested reviewer; their review is listed with the reviews instead (see a review request not shown).

What to do

Check the reviewer: a user GitHub refuses with 422 is not a collaborator of the repository; a repository owner or admin can give them access first.
Check your own access: you need write access, or write or triage permissions as an organization member.
Name teams by slug: team_reviewers takes team slugs.
Ask again after changes: on GitHub, click the sync icon next to the reviewer in the Reviewers sidebar, or use the re-request endpoint (requesting a pull request review).
Mind large teams: requesting a review from a large team can notify every team member; auto assignment, or Only notify requested team members with a specific member requested, reduces that.

In IntelliJ IDEA: the list can offer people and teams that GitHub then refuses

How the GitHub support built into IntelliJ IDEA requests reviews, in its source (checked October 31, 2026; IntelliJ IDEA: GHPRReviewFlowViewModelImpl.kt, GHPRRequestReviewAction.kt, GHPRRepositoryDataServiceExtensions.kt, GHPRRepositoryDataServiceImpl.kt, findOrganizationTeams.graphql, GHPRDetailsServiceImpl.kt, GithubApiRequests.kt):

Who gets the buttons: Request Review…, Re-request Review… and Set Myself as Reviewer are on for the author of the pull request or an account with Triage permission or above, as GitHub reported it when the IDE connected to the repository.
Whom it lists: every team of the organization that owns the repository (the query for teams does not ask which of them can see the repository), and people: with write permission, the repository's collaborators who can push; without it, the repository's contributors, who need not be collaborators. The author of the pull request is left out. So the list can offer someone GitHub refuses with the 422 above.
How it sends: it compares your choice with the current requests. Removals go first, with DELETE .../requested_reviewers; then additions, with POST .../requested_reviewers (logins as reviewers, slugs as team_reviewers). So when an addition is refused, removals made in the same choice have already gone through. Re-request Review… sends the same POST for those who already reviewed, not the rerequest endpoint.
When GitHub refuses, nothing appears on screen: the source writes the error to the IDE's log, where showing it is marked as still to do. The pull request is then loaded again, so the reviewers shown follow GitHub.

GitHub pull requests in IntelliJ IDEA

Pull Request Inbox for GitHub, a plugin by Lesstep for JetBrains IDEs 2024.1 or later, shows a pull request's reviews, checks and conversations next to the diff, and merges it with the methods the target branch allows. It shows the people and teams a pull request asks to review, with the reviews they gave; it does not request reviewers, which you do on GitHub. The review inbox, diffs and conversations are free; approving, commenting, resolving and merging are Pro (US$1.50 a month, with a 30-day trial).

GitHub is a trademark of GitHub, Inc.; IntelliJ IDEA is a trademark of JetBrains s.r.o. This page is not affiliated with or endorsed by GitHub, Inc. or JetBrains.