GitHub REST API新增成本中心反查：按用户、组织、仓库或企业团队直接取成本中心，自定义角色的权限范围在更新日志与文档中说法不同

2026年11月3日，GitHub新增了一个REST API端点，可以告诉你某个资源属于哪个成本中心。更新日志说，可以查询用户、组织、仓库或企业团队。以前，必须列出每个成本中心，再逐个扫描其中的资源。现在把资源类型和名称传给一个端点，响应就会给出成本中心的ID和名称。如果资源不属于任何成本中心，memberships数组会返回为空。

REST文档补充了细节。请求是向企业计费路径下的成本中心成员关系发出GET，带两个查询参数：resource_type，可以是user、repository、organization或team，以及name。对用户和组织，name是登录名；对仓库，写成owner/repo；对团队，是企业团队的slug。企业用slug表示，文档示例发送的API版本是2026-03-10。文档列出的状态码是200、400、403、404、500和503。一个200的示例响应显示用户octocat有一条成员关系，指向名为Engineering Team的成本中心。

访问权限这里需要把两个来源放在一起读，因为它们说法并不完全相同。更新日志说，企业所有者、计费管理员以及对企业计费有读取权限的GitHub App，可以查询企业内的任何资源；然后说，组织所有者以及拥有包含企业计费读取权限的自定义角色的用户，只能查询自己已经能看到的资源和成本中心。REST页面说，企业所有者、计费管理员和企业内的组织所有者可以查看成员关系，对企业计费有细粒度读取权限的自定义角色持有者“也可以查看”，持有该读取权限的GitHub App安装令牌可以获取企业内任何资源的成员关系。页面把组织所有者限制在他们拥有的组织、属于这些组织的用户、他们能看到的仓库以及对他们可见的企业团队。它没有为自定义角色持有者写明限制。所以自定义角色的范围，更新日志是一种说法，文档则没有明说，团队在依赖之前应该用真实的自定义角色测试。

令牌范围也很窄。文档说，这个端点适用于两种细粒度令牌：GitHub App用户访问令牌和GitHub App安装访问令牌，并需要“企业计费”读取级别的权限。它没有为这个端点列出其他令牌类型，因此使用其他凭据的脚本，在迁移到新调用之前应先核对。

实际上它改变了什么？维护仓库和用户清单的财务或平台团队，现在可以直接问“这个仓库由哪个成本中心付费”，而不必下载并关联每个成本中心的资源列表。这应能减少调用并让审计更简单，不过两个来源都没有给出快多少的数字。它也只读取成本中心数据，不改变成本中心如何收费，也不把资源分配给某个成本中心。空的memberships数组是个有用的信号，说明某个资源没有被任何成本中心覆盖，团队可以扫描这类资源来找出没有分摊的支出。

需要提醒的是，这是一个只读查询。它不会替你判断某个资源应该属于哪个成本中心，也不会说明成本中心如何汇总用量或费用。更新日志和文档页都没有给出调用频率限制、批量查询方式或响应时间，需要大量查询的团队应先小范围试用，再决定是否替换现有的“列出并扫描”脚本。

简单概括：新端点让你按资源直接取成本中心，而不必列出所有成本中心再扫描。需要核对三点。第一，更新日志和REST文档对自定义角色的访问范围说法不同，一个写明只能查已经能看到的资源，另一个没有写限制，应以真实的自定义角色测试，不要臆断。第二，文档只列出GitHub App用户访问令牌和安装访问令牌两种细粒度令牌，并要求企业计费读取权限。第三，两个来源都没有给出速度或调用频率限制的数据。空的memberships数组表示资源不属于任何成本中心，可以用来找出没有分摊的支出。

补充一点：请求是向企业计费路径下的成本中心成员关系发出GET，参数是resource_type和name；用户和组织用登录名，仓库写成owner/repo，团队用企业团队的slug。文档列出的状态码是200、400、403、404、500和503，示例响应显示用户octocat属于名为Engineering Team的成本中心。