GitHub cost center lookup API: what it changes for FinOps

On November 3, 2026, GitHub added a REST API endpoint that returns the cost center a resource belongs to. You can ask about a user, an organization, a repository or an enterprise team. Before this, you had to list every cost center and scan its resources to find the answer. If you run GitHub Enterprise and want to know why a bill landed where it did, this is a small but useful tool. The endpoint sits under /enterprises/{enterprise}, so without an enterprise account you can likely ignore it.

What was announced, and what is new?

The endpoint is documented as Get cost center membership for a resource. As of November 2026, the docs describe it like this:

• It is a GET on /enterprises/{enterprise}/settings/billing/cost-centers/memberships.
• You pass resource_type (user, repository, organization or team) and name. For a repository, name is owner/repo. For a team, it is the enterprise team slug.
• The response holds the resource and a memberships array. Each entry has a cost_center object with its id and name. GitHub's announcement says the array is empty when the resource is not in a cost center.

The docs list other cost center endpoints (create, update, archive, add and remove resources). What changed is the reverse lookup: from a resource to its cost center, in one call.

What is a cost center, in GitHub terms?

GitHub's cost center documentation says a cost center attributes usage and spending to parts of your business, and that you can apply one or more budgets to it. A few facts matter for planning:

• An enterprise can have up to 1,000 active cost centers, and each can hold up to 25,000 resources.
• Cost centers apply to metered usage only, not to volume or subscription billing.
• A budget applies to the whole cost center. If two teams need separate budgets, they need separate cost centers.

Which charge goes to which cost center?

The answer depends on the product. GitHub's allocation reference groups it mainly into two patterns: usage-based products follow where the work happens, and license-based products follow the person.

1. Usage-basedrepo or org where it runs
2. License-baseduser who holds the license
3. Fallback for licensesorg billed for the license
4. Resulta cost center, or Enterprise Only

In the reference, GitHub Actions, Codespaces, Git LFS and Packages are allocated by repository or organization. Copilot and GitHub Enterprise licenses, and Advanced Security licenses, are allocated by the user. AI credits follow the user who triggered the usage, and fall back to the organization that granted that user's Copilot license.

Who should care, and who can ignore it?

Care if:

• You are on GitHub Enterprise and finance asks "which team owns this Actions or Copilot spend?"
• You use cost centers and want to audit that new repositories and new hires were actually assigned.
• You build internal tooling, such as an onboarding script or a FinOps report, that needs to check assignment automatically.

Ignore if:

• You do not have an enterprise account. The endpoint sits under /enterprises/{enterprise}.
• Your GitHub spend is small and flat. A spreadsheet is cheaper than a process.

What does it cost, and what are the limits?

The announcement does not mention an extra charge, and we found no separate price for the endpoint in the docs as of November 2026. Treat that as "nothing announced", not "free forever". Access is limited by role:

• Enterprise owners, billing managers and GitHub Apps with read access to enterprise billing can look up any resource in the enterprise.
• Organization owners, and custom roles with read access to enterprise billing, can only look up resources they can already see.

The docs do not state rate limits for this endpoint, so assume the standard REST API limits apply and check them before you loop over thousands of repositories.

How can a team try it safely this week?

1. Pick one identity. Use an enterprise owner or billing manager account, or a GitHub App with read-only access to enterprise billing. Do not create a broad token for a test.
2. Call it for five known resources. Choose a repository, an organization, a user, a team and one resource you believe is unassigned. Send the X-GitHub-Api-Version: 2026-03-10 header that the docs recommend.
3. Compare with what finance expects. If a repository returns an empty memberships array, find out why before you build anything on top.
4. Script a weekly check. List your repositories, look up each one, and report the ones with no cost center. Keep the job read-only.
5. Only then think about budgets. Budgets are set on the cost center as a whole, so fix the grouping first.

What would we check first before adopting it?

We start by asking whether your cost center layout matches how you want to see the bill. A lookup API can only tell you the current state. If you have 40 repositories in one catch-all cost center, a faster lookup will not make the numbers more useful.

Then we look at three things:

• Coverage. How many active repositories and paid users have no cost center? That gap is usually where the surprise spend is.
• Ownership. Who is allowed to move a repository from one cost center to another, and is it logged?
• Fit with the rest of your cloud bill. If AWS or Azure costs use tags and GitHub uses cost centers, the two need a shared naming scheme, or no one can read them side by side.

None of this needs a new tool. It needs one honest hour with the current data. If you want a second pair of senior eyes on how engineering spend is allocated, our services page describes how we work.

This article is general information, not financial or legal advice. Check GitHub's current documentation and your own billing setup before you make decisions.