GitHub Copilot Seat Management API: Provision Access With a GitHub App

GitHub added enterprise GitHub App support to its Copilot seat-management APIs on November 10. An internal provisioning service can now manage user and enterprise-team assignments with an App permission, rather than relying only on the older token paths. The important implementation work is deciding which changes the service should make.

The announcement introduces the enterprise permission named Enterprise Copilot license management. This is a useful opening for teams connecting approved developer onboarding to Copilot access. It should also prompt a review of any script that equates a successful request with the right person having the right access.

Start with a read-only inventory

The REST reference supports GitHub App user and installation tokens. Listing seats needs the permission at read level; assignment changes need write. These endpoints remain public preview.

Use GET /enterprises/{enterprise}/copilot/billing/seats to inventory assignments. Results paginate, with a maximum per_page of 100. Multiple grant rows can represent one person, while total_seats counts that person once.

That difference should shape your data model. Keep one record for the GitHub identity and separate records for the paths granting access. Otherwise, an employee with two assignments can look like two employees in your reconciliation report. Counting rows is a tempting shortcut that produces an unreliable purchasing picture.

Start the rollout in report-only mode. Compare the inventory with an approved eligibility list and have an administrator review the differences. Do not let an empty or incomplete upstream response become an instruction to remove everybody's access.

Add a small, approved enterprise team

For team provisioning, POST /enterprises/{enterprise}/copilot/billing/selected_enterprise_teams with a selected_enterprise_teams array of enterprise-team names. The operation purchases seats and can refresh existing assignments. Only enterprise owners can purchase seats for their members.

Here is an illustrative, untested request body for a hypothetical pilot team. It is not a command to execute against a live enterprise:

{
  "selected_enterprise_teams": ["copilot-pilot"]
}

Before submitting anything, verify that the team contains exactly the intended accounts and that its name belongs to the intended enterprise. Store the reviewed membership snapshot alongside the approval. A short team name makes a request easy to read, but hides the potentially much larger set of people affected by it.

After the request, read assignments again and compare actual identities with the approved set. Save the response and reconciliation result. If the request times out, inspect the resulting state before retrying; a missing response is not evidence that nothing happened.

Review the billing model before provisioning

GitHub's enterprise access guide says seats must still be assigned even when the billing model includes Copilot access through GitHub Enterprise Cloud. Policies, budgets and network requirements should be configured before assignment.

The billing comparison distinguishes Copilot Business and Enterprise, which include usage allowances, from Copilot access, which does not. Under Copilot access, eligible Enterprise Cloud license holders have no additional seat charge; Standalone users cost $10 per month, and usage is metered separately.

Do not infer an API's compatibility with every billing arrangement from a pricing announcement. Confirm the endpoint's documented scope and your enterprise configuration before moving a production workflow. A permission being available does not establish that the account is configured for the operation you want.

Provisioning is also a spending decision. The approval record should say which population is eligible, which billing model applies and who owns the usage budget. An automation that reliably grants access to the wrong population is still a broken automation.

Cancellation is not immediate revocation

The team DELETE endpoint uses the same path and body field. It schedules cancellation at the end of the billing cycle; another enterprise-team grant can preserve access. Treat this as subscription management, not an emergency offboarding mechanism.

GitHub's license-change documentation distinguishes removing seats from revoking access. Billing and access timing vary with the plan and action, and removing a seat does not necessarily end access immediately.

Keep urgent identity offboarding in the organization's established access-control process. Your Copilot reconciliation job should report what it changed and what access remains, rather than label someone “disabled” because it submitted a cancellation request.

A rollout that is easier to trust

A practical first version needs three outputs: the proposed change, the approved change and the observed result. Keep these distinct so an administrator can tell whether a discrepancy came from the eligibility source, the API operation or an overlapping assignment.

For example, if an approved pilot has eight people but the result includes a ninth, stop expanding the rollout and investigate membership changes. If only seven have access, identify the missing account instead of repeatedly submitting the whole team without checking why.

The value of App-based provisioning is a clearer operational owner for recurring access changes. Build around that owner, with a small permission set and evidence for each change, and the process becomes easier to review when somebody inevitably asks why a particular account received a seat.

I'm Paras. I work at the intersection of AI, engineering and distribution.

I help enterprise AI teams explain technical products and operational decisions clearly to developers and buyers.

Book a 30-minute call.