GitHub Adds Cost Center Lookup API for Enterprise Billing: Permissions and Token Limits

This is a read-only lookup. It can't assign, move or remove anything. Even so, it removes a tedious step from billing scripts and support checks.

What the endpoint does​

You pass a resource type and a name. The response returns the matching cost center's ID and name. If the resource isn't assigned to a cost center, the memberships array comes back empty.

The endpoint is:

GET /enterprises/{enterprise}/settings/billing/cost-centers/memberships

Parameters, per GitHub's REST documentation:

• enterprise (path, required): the enterprise slug.
• resource_type (query, required): user, repository, organization or team.
• name (query, required): the resource identifier.
  • For users and organizations, use the login or organization name.
  • For repositories, use owner/repo.
  • For enterprise teams, use the enterprise team slug.

An example request:

curl -L \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer <YOUR-TOKEN>" \
  -H "X-GitHub-Api-Version: 2026-03-10" \
  "[url]https://api.github.com/enterprises/ENTERPRISE/settings/billing/cost-centers/memberships?resource_type=user&name=octocat[/url]"

On GHE.com, swap api.github.com for your enterprise's dedicated api.SUBDOMAIN.ghe.com host.

A successful 200 response contains a resource object and a memberships array. In GitHub's example, the resource is a user with login octocat. The membership entry holds a cost_center object with an id and a name.

Reading the status codes​

The documented codes are 200, 400, 403, 404, 500 and 503. Your script should treat three outcomes differently:

• 200 with a membership: the resource is assigned. Store the ID and name.
• 200 with an empty array: the resource was found but isn't in a cost center. Don't treat this as an error.
• 404: the resource wasn't found. Check the type and name format first. A repository needs owner/repo, and an enterprise team needs its slug rather than its display name.

A 403 usually points to a permission or visibility problem. That is my inference, not a documented diagnosis. See the access section below.

Who can call it, and with what​

GitHub's changelog sets out the role rules:

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

The REST reference spells out the organization-owner limit. Owners can query the organizations they own, users who belong to those organizations, repositories they can see, and enterprise teams visible to them.

Token caveats​

The docs carry a warning for anyone planning app-based automation. GitHub App authentication for enterprise cost-center and budget endpoints is not generally available. The "Enterprise billing" permission isn't available to every enterprise when registering an enterprise-owned app, on GitHub.com or GHE.com. The documentation tells you not to build around GitHub App tokens unless your enterprise can grant that permission.

For enterprise owners and billing managers, the documented route is a personal access token (classic) or an OAuth token with the manage_billing:enterprise scope. The token's user must have access to the requested resources. Fine-grained personal access tokens can't access these enterprise endpoints.

So the changelog's mention of GitHub Apps is accurate, but it may not apply to your enterprise. Check this before you build anything.

What a lookup can and can't tell you​

Finding a resource's cost center doesn't explain a bill. GitHub's billing documentation says cost centers apply only to metered usage, not volume or subscription billing.

Which resource's membership matters depends on the product. According to GitHub's allocation reference:

Precedence rules add complications. A direct user assignment beats an enterprise-team assignment. If a user sits in several enterprise teams assigned to different cost centers, the team created first applies. A user whose only link is organization membership is charged to that organization's cost center, or to the enterprise if the organization has none.

A user lookup therefore shows the user's own assignment. It may not show where every charge tied to that person lands. For per-resource attribution, GitHub points administrators to a detailed usage report and its cost_center_name column.

Two more rules from GitHub's documentation matter when you interpret results:

• A resource can belong to only one cost center at a time. A cost center can hold many resources.
• Enterprise teams can be assigned to a cost center, and membership stays current as people join or leave the team.

Where it fits in GitHub's cost-center API​

Cost-center management through the REST API arrived on June 30, 2025. It covers creating, editing and deleting cost centers, plus adding, removing and reassigning resources. The new lookup adds a quick read for a single resource.

Before this, third-party write-ups described a workaround. Xebia's engineering blog said you could find a user's current cost center in a cost center's resources array, or use the assigned-seats API. At scale that means pulling the whole list.

A sensible way to use it​

1. Confirm which token type your enterprise can use (see the caveats above).
2. Build the query with the correct resource type and name format, URL-encoded.
3. Branch on the result: a membership, an empty array, a 404, or a 403.
4. Log the returned cost center ID and name for reconciliation.
5. Pair it with a detailed usage report when you need to explain actual charges.

Use cases that fit well include pre-checks before a bulk assignment, audits of unassigned users, and support tickets that ask why a repository's spend shows up somewhere unexpected.

Bottom line​

This is a small but practical improvement for enterprise billing automation. It saves an enumerate-and-scan step and gives a clean answer, including an explicit empty result for unassigned resources. Its limits are the token constraints, the visibility rules for organization owners, and the fact that it reports assignment rather than spend.