GitHub Enterprise Cloud now has a direct way to answer a common billing question: which cost center owns this repository, organization, user, or enterprise team? The new REST API lookup removes the need to list every cost center and search through its resources. GitHub announced the endpoint in its November 3, 2026 changelog.
This is useful for platform teams that need to explain spend, check ownership before moving a repository, or build an internal inventory of GitHub usage. A lookup is also easier to automate than scraping the billing UI or scanning a growing list of cost centers.
The endpoint and its four resource types
Send a GET request to /enterprises/ENTERPRISE/settings/billing/cost-centers/memberships. Pass resource_type and name as query parameters. The supported resource_type values are user, repository, organization, and team.
The name value follows the resource: use a login for a user, an organization slug for an organization, owner/repo for a repository, and the enterprise team slug for a team. For example, a repository lookup uses resource_type=repository and name=acme/payments-api.
Read the response without guessing
A successful response identifies the resource and returns a memberships array. Each membership includes the cost center ID and name. An empty memberships array means the resource is not assigned to a cost center, so your automation should treat that as an explicit state instead of a failed lookup.
Permissions are part of the result
Enterprise owners and billing managers can look up resources across the enterprise. Organization owners are limited to resources and cost centers they can already see. A custom role needs fine-grained read access to enterprise billing, and a GitHub App installation token needs read access to enterprise billing. The endpoint is for GitHub Enterprise Cloud, so check the account type before adding it to a shared automation.
A practical workflow for platform teams
Start with a small inventory of repositories and organizations that matter for the next billing review. Resolve each resource directly, store the returned cost-center ID, and keep the resource identifier alongside it. The ID is the stable join key for later cost-center and usage queries.
Next, separate three states in your report: assigned to one or more cost centers, not assigned, and lookup denied or unavailable. Do not turn a 403 into an unassigned resource. It usually means the token or role cannot see that billing data.
Finally, use the result before ownership-changing operations. A repository transfer, organization move, or team reorganization can affect who receives usage attribution. Recording the cost center before and after the change gives finance and engineering a useful audit trail.
Tips for reliable automation
Use the current GitHub API version header, keep billing permissions narrowly scoped, and log identifiers rather than full billing payloads. Treat 404 as a missing resource, 403 as an access problem, and an empty memberships array as a valid unassigned result. If you need to inspect the cost center after the lookup, use its returned ID with the get-cost-center endpoint.
The main improvement is simple: billing ownership is now a direct lookup. That makes cost-center checks practical inside repository inventories, billing reviews, and GitHub administration workflows without downloading and scanning every cost center first. For a complete cost-allocation workflow, GitHub's guide to controlling costs at scale shows how this lookup fits with creating cost centers, adding resources, and verifying assignments.
