GitHub Copilot Code Review API Tutorial: Automate Pull Request Reviews

GitHub added REST and GraphQL API support for Copilot code review on October 2, 2026, turning what was previously a mostly GitHub-interface task into something scripts and internal workflows can trigger directly. The change is available for Copilot Pro, Pro+, Max, Business, and Enterprise plans, and requests can also specify the review effort level.

That makes Copilot code review useful for a different kind of automation: instead of asking a developer to remember to request an AI review after every pull request, your workflow can make the request itself. This tutorial shows the documented REST approach, how the Copilot reviewer is identified, how to verify that a request actually happened, and what changed with the new Balanced default.

The Copilot code review API turns a manual review request into a workflow step

Copilot code review examines pull requests, identifies potential problems, and can provide suggested changes. GitHub currently supports requesting it from GitHub.com, the command-line interface, several development environments, and the REST API. By default, a review is posted as a comment rather than an approval or a request for changes, although organizations can configure Copilot approvals separately.

The API matters because the trigger can now live beside the rest of your automation. A deployment pipeline, repository-management script, or internal developer tool can create or update a pull request and then request Copilot as a reviewer without requiring somebody to open the pull request page. GitHub says the newly supported REST and GraphQL APIs can also accept a review effort choice for an individual request.

Before you make the API request, check access and the pull request

You need a GitHub repository containing a pull request that you have permission to manage, plus authentication suitable for the repository API operation. GitHub documents fine-grained personal access tokens, GitHub App user access tokens, and GitHub App installation access tokens for the REST endpoint that requests reviewers; a fine-grained token needs the repository's Pull requests: write permission.

You also need a Copilot plan that supports the feature. GitHub lists Copilot Pro, Pro+, Max, Business, and Enterprise for the API-based code-review capability. If Copilot is provided through an organization, administrator policies can affect whether code review is available.

Use the documented REST endpoint to request Copilot

GitHub's REST API uses the pull-request review-request endpoint for this operation. The endpoint is POST /repos/{owner}/{repo}/pulls/{pull_number}/requested_reviewers, and its request body accepts a list of reviewer logins and team slugs. GitHub's own Copilot documentation identifies copilot-pull-request-reviewer[bot] as the reviewer login to request.

For example, a shell script can send a request like this after replacing the repository and pull-request values:

curl -L \ -X POST \ -H "Accept: application/vnd.github+json" \ -H "Authorization: Bearer YOUR_TOKEN" \ -H "X-GitHub-Api-Version: 2026-03-10" \ https://api.github.com/repos/OWNER/REPO/pulls/PULL_NUMBER/requested_reviewers \ -d '{"reviewers":["copilot-pull-request-reviewer[bot]"]}'

The important part is the reviewers array. GitHub's API documentation says this endpoint returns 201 Created when the review-request operation succeeds, while insufficient permissions can produce 403 Forbidden. A 422 response can indicate that a requested user is not a collaborator, so your automation should report the response instead of assuming every request succeeded.

Check the request instead of assuming Copilot has started

After sending the request, you can query the requested reviewers endpoint to see which users or teams are still waiting to review the pull request. GitHub documents GET /repos/{owner}/{repo}/pulls/{pull_number}/requested_reviewers for this purpose. Once a requested reviewer submits a review, that reviewer is no longer returned as a requested reviewer and the review can instead be retrieved from the pull request's review collection.

This distinction is useful in automation. A successful POST tells your system that GitHub accepted the review request, while a later review lookup tells it whether Copilot actually produced review output. If your script immediately starts another operation after the POST, it should not describe the pull request as "AI reviewed" unless it has checked for the resulting review.

Use the GraphQL route when your workflow already uses GitHub's schema

Teams already using GitHub's GraphQL API have another supported route. GitHub's GraphQL schema exposes RequestReviewsByLoginInput, whose botLogins field accepts bot logins for requested reviews, including the Copilot reviewer. The mutation operates on the pull request's node ID rather than the owner, repository, and pull-number combination used by the REST endpoint.

The practical choice is straightforward: REST is convenient when your automation already works with repository names and pull-request numbers, while GraphQL fits workflows that already keep GitHub node IDs and use GraphQL mutations. GitHub now describes both API surfaces as supported ways to request Copilot code review.

Choose review depth carefully because Balanced is now the default

There is another change developers need to account for before automating reviews. GitHub changed the built-in Default effort level to Balanced on September 28, 2026. A repository, organization, or user that had explicitly selected Lite kept that explicit setting, but systems relying on the inherited Default can now receive Balanced reviews instead.

GitHub describes Lite as a cost-efficient review aimed at common problems such as bugs, security vulnerabilities, and style inconsistencies. Balanced performs deeper analysis of complex logic, security-sensitive code, and changes spanning services, and GitHub says Balanced can consume more AI credits and marginally more GitHub Actions minutes.

The difference changes how an automated workflow should be designed. A repository handling routine documentation changes does not necessarily need the same review depth as one changing authentication or payment logic. Rather than blindly triggering the deepest available review for every pull request, make the effort selection part of the policy your automation applies to different classes of changes.

Repository instructions can make the review more useful

Triggering Copilot is only half of the integration. GitHub allows repositories to provide review-specific context through files such as .github/copilot-instructions.md, AGENTS.md, and path-specific instruction files. Copilot code review can also read CLAUDE.md, GEMINI.md, and REVIEW.md when those files are present.

This gives an automated review something concrete to work from. A repository can describe its testing expectations, architectural rules, security requirements, or conventions instead of putting the same instructions into every human review request. GitHub also notes that review instructions are read from the pull request's head branch, which means the instructions accompanying the proposed changes can influence that review.

Do not turn a successful Copilot review into an automatic merge decision

Copilot's output still needs engineering judgment. GitHub's documentation says review comments can contain suggested changes, but it also documents limitations around AI-generated findings and makes clear that Copilot reviews are not automatically equivalent to human approval. By default, the review is a comment, and Copilot approvals are a separately configurable public-preview capability.

A sensible first automation therefore has three distinct states: review requested, review received, and merge decision. The first can be handled by your API call, the second by checking GitHub's review data, and the third by your existing tests, branch protections, and human process. Keeping those states separate prevents an API integration from quietly becoming an unchecked merge mechanism.

A small workflow is enough to automate the first useful version

1. Create or identify the pull request you want reviewed.

2. Authenticate your automation with a token that has the repository permissions required to request reviews.

3. POST to the pull-request requested_reviewers endpoint with copilot-pull-request-reviewer[bot] as the reviewer.

4. Record the returned status and pull-request number so the automation can track the request.

5. Check the requested-reviewers and review data after the review has had time to complete.

6. Keep the merge decision separate from the fact that Copilot returned a review.

For a first deployment, test this on a small repository with pull requests containing known issues. Compare what Copilot reports with the defects you intentionally seeded, and check both successful and rejected API requests. That gives you a measurable baseline before the review trigger becomes part of every repository workflow.

The useful part of this API is the automation boundary

GitHub's October 2 change is less about adding another button and more about exposing the review trigger to software. A script can now request Copilot without opening the pull request interface, while the review-effort controls let teams make the depth of that operation part of their workflow design.

The next step is not to make every pull request automatically merge after an AI review. It is to connect the request, verification, tests, and human decision into a workflow where each stage has a clear job. Once those boundaries are explicit, Copilot code review becomes something your development system can call deliberately rather than another manual step developers have to remember.