GitHub REST API Adds Cost Center Lookup by User, Organization, Repository or Enterprise Team, but the Changelog and Docs Describe Custom-Role Access Differently

On November 3, 2026, GitHub added a REST API endpoint that tells you which cost center a resource belongs to. The changelog says you can look up a user, an organization, a repository or an enterprise team. Before, you had to list every cost center and scan the resources in each one. Now you pass the resource type and name to one endpoint, and the response gives the cost center's ID and name. If the resource does not belong to any cost center, the memberships array comes back empty.

The REST documentation fills in the details. The request is a GET to the enterprise billing path for cost center memberships, with two query parameters: resource_type, which can be user, repository, organization or team, and name. For users and organizations the name is the login, for a repository it is written as owner/repo, and for a team it is the enterprise team slug. The enterprise is given as its slug, and the documented example sends API version 2026-03-10. The documented status codes are 200, 400, 403, 404, 500 and 503. A sample 200 response shows a user, octocat, with one membership naming a cost center called Engineering Team.

Access is where the two sources need to be read together, because they do not say exactly the same thing. The changelog says enterprise owners, billing managers and GitHub Apps with read access to enterprise billing can look up any resource in the enterprise. It then says organization owners, and users with custom roles that include read access to enterprise billing, can look up only the resources and cost centers they can already see. The REST page says enterprise owners, billing managers and organization owners in the enterprise can view membership information, that a custom role holder with fine-grained read access to enterprise billing can also view it, and that a GitHub App installation token with that read access can get membership for any resource in the enterprise. The page limits organization owners to organizations they own, users who belong to those organizations, repositories they can see and enterprise teams visible to them. It does not state a limit for custom role holders. So the scope for a custom role is described one way in the changelog and left open in the docs, and teams should test with a real custom role before they rely on it.

The tokens are also narrow. The documentation says the endpoint works with two fine-grained token types, GitHub App user access tokens and GitHub App installation access tokens, and needs the Enterprise billing permission at read level. It lists no other token type for this endpoint, so a script that uses a different credential should be checked before it is moved to the new call.

What does it change in practice? A finance or platform team that keeps an inventory of repositories and users can now ask a direct question, "which cost center pays for this repository," instead of downloading and joining every cost center's resource list. That should cut calls and make audits simpler, though neither source gives numbers for how much faster it is. It also reads cost center data only. It does not change what a cost center charges or assign a resource to one. The empty memberships array is a useful signal, since it shows a resource that no cost center covers, and a team can scan for those to find spend that is not allocated.