Enterprise administrators can now use a GitHub App to automate some Copilot seat assignments. GitHub's November 10 changelog says enterprise GitHub Apps can call the enterprise Copilot seat-management APIs to add users or enterprise teams to a subscription. The change matters for organizations that provision access through an internal tool, but it does not make a GitHub App an enterprise owner or remove the billing consequences of granting seats.
Which permission does the app need?
GitHub introduced a fine-grained enterprise permission named Enterprise Copilot license management. The REST documentation lists that permission at write level for adding users or teams and removing them. GitHub also lists Enterprise administration with write access as an alternative for those endpoints. For an app limited to Copilot seat work, the new permission lets an administrator grant the narrower capability instead of relying on a broader enterprise administration permission. The GitHub App still needs to be installed and authorized for the enterprise.
The API covers two assignment shapes. An enterprise can add selected usernames or add all members of selected enterprise teams. The corresponding removal calls set those users' or teams' seats to pending cancellation. The documentation says access ends at the close of the current billing cycle, unless the person keeps a seat through another team. Adding users purchases seats and bills the enterprise; assigning a team can add seats for every user in that team. This is access provisioning with a real subscription cost, not just a directory setting.
What stays under an owner's control?
GitHub's API reference says only enterprise owners can purchase or cancel Copilot seats for enterprise members. The app permission enables an app token to call the endpoint, but the enterprise owner remains the authority that grants and configures that permission. GitHub documents prerequisites and failure cases too: Copilot and billing must be enabled for the enterprise, and the enterprise's seat-access setting must permit selected assignments. Requests can fail when access is configured for everyone or the setting is not configured.
The enterprise user and team seat-management endpoints are marked public preview and subject to change. GitHub's example uses the enterprise Copilot billing paths and an API version header; customers on GHE.com need the enterprise's dedicated API subdomain. Treat the API as an integration point to test against the current documentation, not a stable contract to hard-code into a provisioning system without monitoring for changes.
How is this different from other Copilot APIs?
The new permission applies to enterprise seat assignment. It does not mean GitHub Apps can manage every Copilot control. For example, GitHub's separate code-review settings API has different authentication rules and its documentation says some enterprise and organization settings endpoints do not accept GitHub Apps. The endpoint and permission must be checked for each workflow; a token that can assign seats does not automatically gain access to model policy, code-review settings, or organization-level seat administration.
For a team building an internal access workflow, the useful next step is to define who may request a seat, which enterprise owner approves the app's installation and permission, and how the tool will report new seats and pending cancellations before it sends a write request. GitHub's API can perform the assignment, but the enterprise still needs a clear approval and billing process.