GitHub Opens Copilot Code Review to REST and GraphQL APIs

Direct answer

GitHub announced on 2 October 2026 that Copilot code review can now be requested through supported REST and GraphQL APIs. A request may specify the review effort level. GitHub also confirmed that Balanced is now the behavior behind the Default effort setting for new and existing repositories and organizations using Copilot code review.

What changed

API support moves Copilot review beyond a manual pull-request action. Engineering teams can initiate a review from an internal developer portal, release workflow, policy check, or another system that already coordinates pull requests. The operational boundary remains important: an API-triggered review is one review signal, not an approval substitute.

GitHub lists Copilot Pro, Pro+, Max, Business, and Enterprise among eligible plans. An explicitly selected Lite setting remains intact; Balanced applies where configuration is left at Default.

Implementation checklist

1. Define which pull requests warrant an automated review instead of triggering every review indiscriminately. 2. Record the requested effort level and result in existing engineering telemetry. 3. Keep branch protection, human ownership, security review, and required tests independent from Copilot output. 4. Measure actionable findings, false positives, review latency, and cost.

Administration is hierarchical across enterprise, organization, repository, and personal settings. Teams should document the effective configuration instead of assuming one global setting reaches every repository.

Why it matters

API access makes review easier to compose into engineering systems, but it can also create noisy or redundant feedback. The useful implementation has explicit eligibility, ownership, and success metrics.

Source

• GitHub Changelog: Copilot code review API support and new default effort level

FAQ

Can API-triggered Copilot review approve a production change by itself? It should not. Keep human approvals, tests, security controls, and branch protection as separate gates.

What should an organization measure? Track review coverage, actionable findings, false-positive rate, time to merge, review cost, and whether developers accept or dismiss the feedback.