Pull Requests per REST API in Azure DevOps lassen sich in Azure DevOps Services lesen und bearbeiten. Sie können Pull-Request-Daten abrufen, Diskussionen auswerten sowie Kommentare, Votes und andere Signale im Rahmen der Berechtigungen der verwendeten Identität setzen.
Entscheidend ist dabei weniger der einzelne Endpunkt als das Betriebsmodell darum herum. Eine technische Identität handelt nie losgelöst von Repository-Rechten, Branch-Schutz und der Frage, welche Spur im Review sichtbar sein soll.
Für die Praxis sind meist diese Punkte zuerst wichtig:
- Welche Identität ruft die API auf
- welche Aktion im Pull Request wirklich gebraucht wird
- welche Regeln im Ziel-Branch bereits gelten
- ob ein Signal nur informieren oder den Prozess beeinflussen soll
Wenn Sie den Ablauf davor oder daneben einordnen möchten, helfen einen Pull Request erstellen, Work Items verknüpfen, Service Hooks für Pull Requests, Draft-Pull-Requests und wer Regeln umgehen darf.
Authentifizierung: Entra-Token, Service Principals und PAT
Für Pull Requests per REST API ist nicht nur wichtig, ob der Aufruf funktioniert, sondern unter welcher Identität er im Projekt erscheint. Genau diese Identität bestimmt, welche Rechte gelten und wie Aktivitäten im Pull Request für Ihr Team sichtbar werden.
In Azure DevOps Services sind dafür typischerweise drei Wege relevant:
- Entra-Token für Aufrufe im Benutzerkontext
- Service Principals für technische Identitäten
- PATs als persönliche Zugriffstoken
Ein Service Principal ist eine technische Identität für automatisierte Zugriffe. Er eignet sich, wenn ein Dienst wiederkehrend mit Azure DevOps arbeitet und seine Rechte getrennt von einzelnen Benutzerkonten verwaltet werden sollen.
Ein Entra-Token passt, wenn ein Mensch bewusst im eigenen Kontext handelt und dabei mit den Rechten seiner normalen Rolle arbeitet. Das ist vor allem dann passend, wenn die Aktion im Pull Request auch sichtbar dieser Person zugerechnet werden soll.
PATs sind für Prototypen oder kleine Hilfsskripte oft naheliegend. Im Team-Betrieb werden sie jedoch schnell unübersichtlich, weil sie an Personen gebunden sind und organisatorisch sauber gepflegt werden müssen.
Praktisch hilft vor der Umsetzung eine kurze Festlegung:
- Welche Aktionen braucht die Integration wirklich?
- Soll sie als Mensch oder als technischer Dienst erscheinen?
- Wo sollen die Rechte verwaltet und überprüft werden?
Für viele Automatisierungen ist damit weniger die Token-Art entscheidend als ein klares Identitätsmodell.
Pull Requests, Iterationen und Threads richtig lesen
Wenn Sie Pull Requests per REST API auswerten, reicht der Blick auf Titel, Beschreibung und den aktuellen Diff meist nicht aus. Entscheidend ist, welcher Stand geprüft wird und wo die Diskussion dazu stattfindet.
Eine Iteration ist die Fassung eines Pull Requests nach einem weiteren Push auf den Quellbranch. Damit erkennen Sie, ob ein Hinweis noch zum aktuellen Stand gehört oder sich auf eine ältere Änderung bezieht.
Ein Thread ist ein zusammengehöriger Diskussionsstrang im Pull Request. Er kann an eine Datei und Position gebunden sein oder allgemein zum gesamten Pull Request laufen.
Für belastbare Auswertung sollten Sie mindestens diese Ebenen getrennt lesen:
- den Zustand des Pull Requests selbst
- die Iterationen als zeitliche Folge
- die Threads als fachliche Diskussion
- den Status eines Threads, also offen oder erledigt
Gerade bei dateibezogenen Threads ist der Kontext wichtig. Ein Kommentar an einer Zeile ist technisch etwas anderes als ein allgemeiner Hinweis ohne Dateibindung. Wer nur den neuesten Diff liest, übersieht leicht, dass ein offener Punkt aus einer früheren Iteration noch nicht sauber beantwortet ist.
Hilfreich ist außerdem ein Blick auf die Größe des Änderungspakets. Sehr große Pull Requests machen auch das reine Lesen per API unübersichtlicher. Für die Einordnung hilft die Frage nach der Pull-Request-Größe.
Kurz gesagt: Lesen Sie nicht nur den Antrag, sondern auch seine Entwicklung und die daran hängenden Gespräche. Erst daraus entsteht ein Bild, das für Automatisierung und Review-Auswertung brauchbar ist.
Kommentare, Threads und Votes per API setzen
Per REST API sollten Sie im Pull Request sauber zwischen Gespräch und Entscheidungssignal unterscheiden. Ein Thread bündelt zusammengehörige Kommentare an einer Stelle. Ein Vote ist dagegen die Bewertung einer Identität für den gesamten Pull Request.
Für die Einbindung in eigene Abläufe hilft diese Trennung:
- Kommentare für konkrete Hinweise zum Inhalt
- Threads für den Zusammenhang einer Diskussion
- Votes nur dann, wenn ihre Wirkung im Ziel-Branch wirklich gewollt ist
Das ist vor allem bei technischen Identitäten wichtig. Wer automatisch schreibt, sollte nicht bei jedem Fund einen neuen Thread eröffnen. Sinnvoller ist oft, bestehende Threads erst mitzulesen und nur dann einen neuen Strang anzulegen, wenn es tatsächlich um einen anderen Punkt geht. Sonst wächst die Review-Fläche, ohne dass der Erkenntnisgewinn steigt.
Für Votes gilt noch stärker: Nicht der API-Endpunkt steuert den Prozess, sondern die Branch Policy. Azure Repos kennt dafür unter anderem Mindestanzahl an Reviewern, verknüpfte Work Items, Kommentarauflösung, Build Validation, Status Checks, erlaubte Merge-Typen und automatisch einbezogene Reviewer. Nach Microsoft Learn, „Branch policies overview“, „Branch policies“ und „Securely use repositories and pull requests in Azure Repos“, gelesen am 01.11.2026, sind diese Regeln zunächst ausgeschaltet.
In vielen Fällen ist deshalb ein Status Check das präzisere Signal. Damit meldet ein externer Dienst ein Ergebnis, ohne sich als eigentlicher Reviewer auszugeben. Ob daraus eine erforderliche Regel wird, entscheidet Ihr Team über die Policy des Branches.
Für den Weg von Azure Boards zu Pull Requests in Azure Repos ist Polier in Entwicklung und am 01.11.2026 noch nicht verfügbar.
Rate Limits, Größe und saubere Automatisierung
Für Pull-Request-Automatisierung ist nicht entscheidend, möglichst viele Aufrufe parallel abzusetzen. Wichtiger ist ein Ablauf, der mit Lastspitzen, Wiederholungen und unvollständigen Zwischenständen ruhig umgeht.
Bewährt haben sich drei einfache Regeln:
- denselben Pull Request nicht fortlaufend komplett neu lesen
- neue Daten schrittweise verarbeiten statt alles jedes Mal neu zu berechnen
- Wiederholungen mit Backoff planen, also mit steigenden Wartezeiten nach Fehlern
Gerade bei größeren Änderungen steigt der Aufwand schnell. Mehr Dateien, mehr Threads und mehr Iterationen machen die Auswertung unübersichtlicher und erhöhen die Zahl der nötigen API-Aufrufe.
Ein greifbarer Referenzpunkt kommt aus Microsofts Dokumentation zu Copilot Code Review: geprüft werden nur aktive Pull Requests ohne Merge-Konflikte, in Repositories bis 10 GB, mit bis zu 100 geänderten Dateien und 100 Changes; zusätzlich gelten Grenzen für gleichzeitige Reviews. Quelle: Microsoft Learn, „Copilot code reviews“, gelesen am 01.11.2026. Wenn ein Pull Request Konflikte hat, sollten Automatisierungen deshalb besonders zurückhaltend reagieren; fachlich ist das ein anderer Zustand als ein normales Review. Dazu passt auch der Blick auf Konflikte im Pull Request.
Planen Sie daher eher defensiv: wenige gezielte Aufrufe, klare Wiederholungslogik und zurückhaltende Reaktionen bei großen oder konfliktbehafteten Pull Requests.
Einordnung für Azure DevOps Services heute
Dieser Beitrag meint den Stand in Azure DevOps Services. Für Azure DevOps Server sollten Sie dieselben API-Ideen nicht einfach übernehmen, weil Microsoft für einzelne Integrationen und KI-Funktionen andere Grenzen dokumentiert.
Zum Stand am 24.10.2026 beziehungsweise 01.11.2026 nennt Microsoft unter anderem:
- Copilot Code Review ist für Azure DevOps Server nicht verfügbar.
- Die Azure DevOps MCP-Server unterstützten Azure DevOps Server am 24.10.2026 nicht.
- Microsoft zeigt seinen Ausbau eher bei Services und in Richtung Repository-Migrationen.
Für die Architektur ist außerdem relevant: Laut Release Notes Sprint 279 kann Azure DevOps Enterprise Live Migrations Repositories nach GitHub Enterprise Cloud verschieben, einschließlich Historie, Branches, Tags, Pull-Request-Metadaten und Branch Policies; Boards und Pipelines können weiter genutzt werden. Wenn Sie Ihre Repository-Wahl neu bewerten, hilft eine nüchterne Einordnung von Azure Repos oder GitHub.
Sobald Pull-Request-Inhalte, Kommentare oder Quellcode automatisiert verarbeitet werden, stellen sich Fragen zu Datenschutz, DORA, NIS2 und Mitbestimmung. Klären Sie das mit Ihrer Rechtsabteilung, anwaltlicher Beratung oder dem Datenschutzbeauftragten.
Häufige Fragen
Welche API-Aktion passt zu welchem Signal im Review?
Nicht jede Schreiboperation im Pull Request hat dieselbe Bedeutung. Für die Praxis hilft eine einfache Trennung:
- Kommentar, wenn Sie einen konkreten Hinweis ablegen wollen
- Thread, wenn mehrere Hinweise zusammengehören
- Vote, wenn eine Identität eine Bewertung zum gesamten Pull Request abgibt
- Status, wenn ein externer Dienst ein Ergebnis an den Pull Request hängt
Ein Status ist ein maschinenlesbares Signal. Er kann in Azure Repos als Pflichtregel eingebunden werden, ohne dass der Dienst selbst als menschlicher Reviewer auftritt.
Was bleibt im Pull Request sichtbar, wenn ein Dienst per API arbeitet?
Sichtbar bleibt immer die Identität, unter der die Aktion ausgeführt wurde. Das betrifft Kommentare, Votes, Statusmeldungen und ihre zeitliche Reihenfolge. Für Teams ist daher wichtig, vorab festzulegen, ob eine Aktion bewusst im Benutzerkontext oder über eine technische Identität erscheinen soll.
Wenn Sie für solche Integrationen auch die Fragen zu Datenweg, Identitäten und Guardrails einordnen möchten, finden Sie den geplanten und den heute geltenden Stand auf der Seite zu Sicherheit und Daten.
Wo liegen die Grenzen bei KI-gestützter Pull-Request-Prüfung in Azure DevOps?
Nach Microsoft Learn, „Copilot code reviews“, gelesen am 01.11.2026, werden nur aktive Pull Requests ohne Merge-Konflikte geprüft, in Repositories bis 10 GB, mit bis zu 100 geänderten Dateien und 100 Changes. Nach Microsoft Learn, „Review pull requests“, gelesen am 01.11.2026, hinterlässt diese Prüfung immer eine Kommentar-Review und erfüllt damit keine Required-Reviewer-Policy.
Preview-Funktionen können sich ändern und haben keine SLA. Für belastbare Aussagen zu gemessenen Ergebnissen sollten Sie auf spätere Messwerte schauen, nicht auf Annahmen.
Wo sieht man Änderungen am Stand und an geplanten Funktionen?
Wenn Sie den aktuellen Stand später erneut prüfen wollen, ist ein öffentlicher Änderungsverlauf sinnvoller als eine einmal gelesene Beschreibung. Dafür ist der öffentliche Änderungsverlauf gedacht.
Weitere Informationen zu Anmeldung und Paketen finden Sie bei Bedarf auf der Seite zu Anmeldung und Abo-Modell.
Nächster Schritt
Legen Sie vor dem ersten API-Aufruf fest, woran Sie den Versuch bewerten. Für diesen Einstieg genügen wenige Fragen:
- Welches Signal soll im Pull Request sichtbar werden?
- Welche Entscheidung trifft Ihr Team weiterhin selbst?
- Welche Daten müssen Sie dafür wirklich verarbeiten?
Arbeiten Sie dann mit einem bewusst kleinen Ablauf und halten Sie Abbruchkriterien fest, etwa bei unklarem Review-Zustand oder fehlendem Kontext.
Falls für Sie der Pfad von einem Azure Boards Work Item zu einem Pull Request in Azure Repos relevant ist: Polier ist in Entwicklung und am 01.11.2026 noch nicht verfügbar.