GitHub REST API ergänzt Kostenstellen-Abfrage nach Benutzer, Organisation, Repository oder Enterprise-Team, doch Changelog und Dokumentation beschreiben den Zugriff benutzerdefinierter Rollen unterschiedlich

Am 3. November 2026 hat GitHub einen REST-API-Endpunkt hinzugefügt, der angibt, zu welcher Kostenstelle eine Ressource gehört. Laut Changelog lassen sich ein Benutzer, eine Organisation, ein Repository oder ein Enterprise-Team abfragen. Zuvor musste man alle Kostenstellen auflisten und die Ressourcen jeder einzelnen durchsuchen. Jetzt übergibt man Ressourcentyp und Name an einen Endpunkt, und die Antwort liefert die ID und den Namen der Kostenstelle. Gehört die Ressource zu keiner Kostenstelle, kommt das Array memberships leer zurück.

Die REST-Dokumentation liefert die Details. Die Anfrage ist ein GET auf den Enterprise-Abrechnungspfad für Kostenstellen-Mitgliedschaften, mit zwei Abfrageparametern: resource_type, der user, repository, organization oder team sein kann, und name. Bei Benutzern und Organisationen ist der Name der Login, bei einem Repository wird er als owner/repo geschrieben, bei einem Team ist es der Slug des Enterprise-Teams. Das Enterprise wird über seinen Slug angegeben, und das dokumentierte Beispiel sendet die API-Version 2026-03-10. Die dokumentierten Statuscodes sind 200, 400, 403, 404, 500 und 503. Eine Beispielantwort mit 200 zeigt den Benutzer octocat mit einer Mitgliedschaft in einer Kostenstelle namens Engineering Team.

Beim Zugriff müssen beide Quellen zusammen gelesen werden, weil sie nicht genau dasselbe sagen. Der Changelog sagt, Enterprise-Eigentümer, Abrechnungsmanager und GitHub Apps mit Lesezugriff auf die Enterprise-Abrechnung könnten jede Ressource im Enterprise nachschlagen. Danach heißt es, Organisationseigentümer und Benutzer mit benutzerdefinierten Rollen, die Lesezugriff auf die Enterprise-Abrechnung enthalten, könnten nur Ressourcen und Kostenstellen nachschlagen, die sie ohnehin sehen. Die REST-Seite sagt, Enterprise-Eigentümer, Abrechnungsmanager und Organisationseigentümer im Enterprise könnten die Mitgliedschaften einsehen, ein Inhaber einer benutzerdefinierten Rolle mit fein abgestuftem Lesezugriff auf die Enterprise-Abrechnung könne sie „ebenfalls“ einsehen, und ein Installations-Token einer GitHub App mit diesem Lesezugriff könne die Mitgliedschaft jeder Ressource im Enterprise abrufen. Die Seite beschränkt Organisationseigentümer auf Organisationen, die ihnen gehören, auf Benutzer dieser Organisationen, auf Repositories, die sie sehen, und auf für sie sichtbare Enterprise-Teams. Für Inhaber benutzerdefinierter Rollen nennt sie keine Grenze. Der Umfang für eine benutzerdefinierte Rolle ist also im Changelog auf eine Weise beschrieben und in der Dokumentation offen gelassen; vor dem Verlassen darauf sollte man mit einer echten benutzerdefinierten Rolle testen.

Auch die Tokens sind eng gefasst. Die Dokumentation sagt, der Endpunkt funktioniere mit zwei fein abgestuften Token-Typen, GitHub-App-Benutzerzugriffs-Tokens und GitHub-App-Installationszugriffs-Tokens, und brauche die Berechtigung „Enterprise billing“ auf Leseebene. Weitere Token-Typen nennt sie für diesen Endpunkt nicht; ein Skript mit anderen Zugangsdaten sollte daher geprüft werden, bevor es auf den neuen Aufruf umgestellt wird.

Was ändert sich in der Praxis? Ein Finanz- oder Plattformteam, das ein Inventar von Repositories und Benutzern führt, kann jetzt direkt fragen, „welche Kostenstelle bezahlt dieses Repository“, statt die Ressourcenliste jeder Kostenstelle herunterzuladen und zu verknüpfen. Das dürfte Aufrufe verringern und Audits einfacher machen, doch keine der beiden Quellen nennt Zahlen dazu, wie viel schneller es ist. Der Endpunkt liest außerdem nur Kostenstellendaten. Er ändert nicht, was eine Kostenstelle abrechnet, und ordnet keine Ressource einer Kostenstelle zu. Das leere Array memberships ist ein nützliches Signal, denn es zeigt eine Ressource, die keine Kostenstelle abdeckt, und ein Team kann danach suchen, um nicht zugeordnete Ausgaben zu finden.