Pull requests via REST API in Azure DevOps can be read and updated in Azure DevOps Services. You can retrieve pull request data, assess discussions, and set comments, votes and other signals within the permissions of the identity being used.
What matters most is not so much the individual endpoint as the operating model around it. A technical identity never acts independently of repository permissions, branch protection and the question of what trail should be visible in the review.
In practice, these points are usually the first ones that matter:
- which identity is calling the API
- which action is actually needed in the pull request
- which rules already apply on the target branch
- whether a signal is only meant to inform or should influence the process
If you would like to place the workflow before or alongside this in context, these pages will help: create a pull request, link work items, service hooks for pull requests, draft pull requests and who may bypass rules.
Authentication: Entra tokens, service principals and PATs
For pull requests via REST API, what matters is not only whether the call works, but under which identity it appears in the project. That identity determines which permissions apply and how activities in the pull request are shown to your team.
In Azure DevOps Services, three options are typically relevant:
- Entra tokens for calls in a user context
- Service principals for technical identities
- PATs as personal access tokens
A service principal is a technical identity for automated access. It is suitable when a service works with Azure DevOps repeatedly and its permissions should be managed separately from individual user accounts.
An Entra token is the right fit when a person is deliberately acting in their own context and using the permissions of their normal role. This is particularly appropriate if the action in the pull request should also be visibly attributed to that person.
PATs are often an obvious choice for prototypes or small helper scripts. In team operations, however, they quickly become hard to manage because they are tied to individuals and need to be maintained properly from an organisational perspective.
In practice, it helps to clarify a few points before implementation:
- Which actions does the integration actually need?
- Should it appear as a person or as a technical service?
- Where should permissions be managed and reviewed?
For many automations, a clear identity model matters more than the token type itself.
Reading pull requests, iterations and threads properly
When assessing pull requests via REST API, looking only at the title, description and current diff is usually not enough. What matters is which revision is being reviewed and where the related discussion is taking place.
An iteration is the state of a pull request after another push to the source branch. It lets you see whether a remark still relates to the current state or refers to an older change.
A thread is a related discussion thread in the pull request. It may be tied to a file and position, or it may apply to the pull request as a whole.
For a reliable assessment, you should at least read these levels separately:
- the state of the pull request itself
- the iterations as a sequence over time
- the threads as the substantive discussion
- the status of a thread, in other words open or resolved
Context matters especially for file-related threads. Technically, a comment on a specific line is different from a general remark with no file reference. If you only read the latest diff, it is easy to miss that an open point from an earlier iteration has still not been properly addressed.
It is also helpful to look at the size of the change set. Very large pull requests make even simple reading via API harder to follow. For context, it helps to consider the question of pull request size.
In short: do not just read the request itself, but also its development and the conversations attached to it. Only then do you get a picture that is useful for automation and review assessment.
Setting comments, threads and votes via API
When using the REST API, you should clearly distinguish in a pull request between conversation and decision signal. A thread groups related comments in one place. A vote, by contrast, is an identity’s assessment of the pull request as a whole.
For integrating this into your own workflows, the following distinction helps:
- comments for specific remarks on the content
- threads for the context of a discussion
- votes only if their effect on the target branch is genuinely intended
This matters particularly for technical identities. If something writes automatically, it should not open a new thread for every finding. It is often better to read existing threads first and only start a new one if it is genuinely about a different point. Otherwise, the review surface grows without increasing the insight gained.
This is even more true for votes: it is not the API endpoint that controls the process, but the branch policy. Azure Repos supports, among other things, a minimum number of reviewers, linked work items, comment resolution, build validation, status checks, allowed merge types and automatically included reviewers. According to Microsoft Learn, “Branch policies overview”, “Branch policies” and “Securely use repositories and pull requests in Azure Repos”, accessed on 01.11.2026, these rules are disabled by default.
In many cases, a status check is therefore the more precise signal. It lets an external service report a result without presenting itself as an actual reviewer. Whether that becomes a required rule is decided by your team through the branch policy.
Polier is in development for the path from Azure Boards to pull requests in Azure Repos and is not yet available as of 01.11.2026.
Rate limits, size and clean automation
For pull request automation, the key is not to send as many calls as possible in parallel. What matters more is a workflow that handles load spikes, retries and incomplete intermediate states calmly.
Three simple rules have proved effective:
- do not keep rereading the same pull request in full
- process new data incrementally instead of recalculating everything each time
- plan retries with backoff, in other words with increasing wait times after errors
The effort rises quickly, especially with larger changes. More files, more threads and more iterations make assessment harder to follow and increase the number of API calls required.
A tangible reference point comes from Microsoft’s documentation on Copilot code review: only active pull requests without merge conflicts are reviewed, in repositories up to 10 GB, with up to 100 changed files and 100 changes; there are also limits on concurrent reviews. Source: Microsoft Learn, “Copilot code reviews”, accessed on 01.11.2026. If a pull request has conflicts, automations should therefore react especially cautiously; in substantive terms, that is a different state from a normal review. In this context, it also helps to look at conflicts in a pull request.
So plan defensively: make few targeted calls, use clear retry logic and respond cautiously to large or conflict-affected pull requests.
Context for Azure DevOps Services today
This article refers to the current state in Azure DevOps Services. For Azure DevOps Server, you should not simply transfer the same API ideas, because Microsoft documents different limits for certain integrations and AI features.
As of 24.10.2026 and 01.11.2026 respectively, Microsoft states, among other things:
- Copilot code review is not available for Azure DevOps Server.
- The Azure DevOps MCP servers did not support Azure DevOps Server as of 24.10.2026.
- Microsoft’s expansion is focused more on Services and towards repository migrations.
This is also relevant for architecture: according to the Sprint 279 release notes, Azure DevOps Enterprise Live Migrations can move repositories to GitHub Enterprise Cloud, including history, branches, tags, pull request metadata and branch policies; Boards and Pipelines can continue to be used. If you are reassessing your choice of repository platform, a sober assessment of Azure Repos or GitHub may help.
As soon as pull request content, comments or source code are processed automatically, questions arise around data protection, DORA, NIS2 and co-determination. Clarify this with your legal department, legal counsel or data protection officer.
Frequently asked questions
Which API action fits which signal in the review?
Not every write operation in a pull request means the same thing. In practice, this simple distinction helps:
- comment if you want to leave a specific remark
- thread if several remarks belong together
- vote if an identity is giving an assessment of the pull request as a whole
- status if an external service attaches a result to the pull request
A status is a machine-readable signal. In Azure Repos, it can be integrated as a required rule without the service itself appearing as a human reviewer.
What remains visible in the pull request when a service works via API?
What remains visible is always the identity under which the action was performed. This applies to comments, votes, status messages and their chronological order. For teams, it is therefore important to decide in advance whether an action should deliberately appear in the user context or through a technical identity.
If you would also like to place questions around data paths, identities and guardrails for such integrations in context, you can find both the planned position and the rules that already apply today on the page about security and data.
Where are the limits of AI-supported pull request review in Azure DevOps?
According to Microsoft Learn, “Copilot code reviews”, accessed on 01.11.2026, only active pull requests without merge conflicts are reviewed, in repositories up to 10 GB, with up to 100 changed files and 100 changes. According to Microsoft Learn, “Review pull requests”, accessed on 01.11.2026, this review always leaves a comment review and therefore does not satisfy a required reviewer policy.
Preview features may change and do not have an SLA. For robust statements on measured results, you should look at later metrics rather than assumptions.
Where can you see changes to the current status and planned features?
If you want to check the current status again later, a public change log is more useful than a description you read once. That is what the public change log is for.
If needed, you can find further information on sign-up and packages on the page about sign-up and subscription model.
Next step
Before making the first API call, decide how you will assess the attempt. For this starting point, a few questions are enough:
- Which signal should be visible in the pull request?
- Which decision will your team continue to make itself?
- Which data do you actually need to process for that?
Then work with a deliberately small workflow and define stop criteria, for example if the review state is unclear or context is missing.
If the path from an Azure Boards work item to a pull request in Azure Repos is relevant to you: Polier is in development and is not yet available as of 01.11.2026.