Manage Enterprise Copilot Seats with a GitHub App: Permissions and Steps

What changed, and who is it for?

GitHub's November 10, 2026 changelog confirms that Enterprise GitHub Apps can call enterprise-level Copilot seat-management APIs to control which users and enterprise teams receive seats. It introduces the enterprise fine-grained permission Enterprise Copilot license management. This concerns license assignment, rather than usage reports or code-review budgets.

The enterprise seat-list documentation covers enterprises with a Copilot Business or Copilot Enterprise subscription. These endpoints remain in public preview and may change. Do not extend this announcement to personal plans, every organization-level API or GitHub Enterprise Server; check documentation for the actual deployment environment.

The documentation permits enterprise owners to purchase or cancel seats for enterprise members. Enterprise owners and billing managers can view seat assignments across child organizations and enterprise teams. Run automation within the authorized enterprise App's scope; the announcement does not replace enterprise approval.

Separate query permissions from write permissions

Enterprise endpoints support GitHub App user access tokens and GitHub App installation access tokens. Queries can use Enterprise Copilot license management with read access. Adding users or enterprise teams, and cancelling those assignments, require write access. Verify the actual token type and enterprise installation grant as well as the App's configured permissions.

The current documentation also accepts the corresponding read or write level of Enterprise administration. The new dedicated permission offers a more focused grant. Avoid expanding unrelated permissions for seat automation, and do not substitute the older organization-level GitHub Copilot Business permission for an enterprise permission.

Start inventory with GET /enterprises/{enterprise}/copilot/billing/seats, replacing {enterprise} with the enterprise slug. Pagination defaults to 50 results per page and permits at most 100. Read every page for a complete inventory. A successful query establishes that the read completed, not that subsequent writes are authorized.

Match user and enterprise-team paths to their parameters

Assign users with POST /enterprises/{enterprise}/copilot/billing/selected_users. Its selected_usernames body parameter is an array of enterprise-member username strings. Assign enterprise teams with POST /enterprises/{enterprise}/copilot/billing/selected_enterprise_teams, using selected_enterprise_teams as an array of enterprise-team name strings.

For a hypothetical enterprise team named security-review, first confirm the team's identity and membership scope, then put that name in selected_enterprise_teams. The name is only an example. The organization-level selected_teams parameter is different; the two kinds of team are not interchangeable.

The documentation describes adding seats as purchasing them and says the enterprise is billed accordingly. The response reports newly created seats and existing seats that were refreshed. Submitted username counts, team counts or one successful response do not establish the final additional billable-user count. Execute after the enterprise owner confirms scope and cost, then query the resulting assignments.

Cancellation does not immediately remove every access path

To cancel user or enterprise-team assignments, use DELETE on the corresponding path with selected_usernames or selected_enterprise_teams respectively. The documentation says affected seats are set to pending cancellation, generally losing access through that path at the end of the current billing cycle. This is not a promise of immediate complete revocation or a refund.

Enterprise-team members may retain access through another enterprise team. A user whose direct assignment is cancelled may retain access through team or organization membership. Check every actual grant when reviewing access. Use the enterprise's billing schedule for the precise cycle end; do not assume one date or time zone applies to every account.

The enterprise-team removal endpoint also lists 202 Accepted. After an accepted response, check seat status and the pending-cancellation outcome. An HTTP success status alone does not establish that every member has already lost access.

Integrate and troubleshoot in this order

First, confirm the enterprise subscription, billing setup, public code-suggestion policy and target members or enterprise teams. Have the enterprise owner approve the actual change scope. These endpoints are previews: retain the API version and corresponding documentation so future changes are not mistaken for the current contract. This guide checked documentation version 2026-03-10.

Second, use the read-only list to verify identity, enterprise slug, permissions and pagination, then grant the required write access for approved assignments or cancellations. Record operation targets, original responses and subsequent query results. If an outcome is uncertain, inspect current assignments before blindly repeating an operation that changes billing.

Third, diagnose the original error. The documentation lists responses including 401, 403 and 404. A 422 from the user-addition endpoint can involve Copilot not being enabled, incomplete billing or public code-suggestion policy setup, or access configured for all users or left unconfigured. Correct permissions do not establish that these prerequisites are satisfied.

Fourth, query the actual seats, access sources and pending-cancellation state before updating internal records. This guide checks public documentation. It has not called an enterprise account API, purchased or cancelled real seats, or verified a particular enterprise's enablement or commercial terms.