[Feedback] Enterprise Installations for GitHub Apps and installation automation - Public Preview

[hpsin]

Enterprise installations for GitHub Apps

See the changelog here: https://github.blog/changelog/2025-07-01-enterprise-level-access-for-github-apps-and-installation-automation-apis

This space is for feedback about the ability to install apps on the enterprise account and manage the enterprise via APIs. We've also shipped a new API that allows you to manage which apps are installed in your organizations, letting you audit, add, and remove GitHub App installations as well as control which repos they have access to.

We'll post known issues, bug reports, and updates here.

In particular we're interested in understanding what enterprise APIs you'd like us to prioritize for GitHub App support.

[jeffwilcox]

Today we're using enterprise admin read-only classic PATs (enterprise:read scope) to read our Copilot-related telemetry, seat use APIs, etc. Would love to see a granular permission for that to move beyond PATs.

Full disclosure... have not yet tried to see if magically an enterprise app just works for those.

[hpsin]

It's not supported yet, but it's certainly on the roadmap.

[immi234]

exactly

[jeffwilcox]

I have a public GitHub App that has enterprise permissions; but I'm not seeing one of my enterprise a
ccounts showing up as a valid option. Is there a certain criteria for what will appear in this UI?

(This app is 'hosted' in the microsoftopensource enterprise but I have another GHEC enterprise I'm hoping to install this app on which this account is also an enterprise admin on, but not appearing for some reason)

[hpsin]

Ah, right now we're restricting enterprise installations to apps owned within an enterprise. This does block cross enterprise use and third party app development, so we're definitely looking forward to lifting that restriction as we continue development.

[jeffwilcox]

Ah thanks. I missed that in the blog post "Currently, enterprises can only install apps owned by the enterprise or organizations in the enterprise. We’ll lift this limitation in the future as we expand controls around these applications." thx

[jeffwilcox]

Any way to unaccept my non-answer as the answer for this discussion?

[hpsin]

Fixed :)

[amulya-blip]

Hi hpsin
I need your team to contact me through amulya@jirishealth.com as i need support in integrating copilot to our company and we have questions regarding security and some other. Please do the needful

[jeffwilcox]

"In particular we're interested in understanding what enterprise APIs you'd like us to prioritize for GitHub App support"

I'm not able to call a pretty basic read-only GraphQL function; should there be a discrete "read-only enterprise metadata" granular permission for enterprise apps available?

I can use a classic PAT of an enterprise admin with read:enterprise for this call but not my fancy new GitHub Enterprise-authorized and installed app...

(Just calling the name of my own enterprise; yes, in theory, these are mostly-constant values coming back)

    query getEnterprise($enterpriseName: String!) {
      enterprise(slug: $enterpriseName) {
        id
        name
        slug
      }
    }

[jeffwilcox]

This is working now, thank you.

[qaisjp]

@jeffwilcox how did you get this to work?

With this query:

query IsEnterpriseMember { enterprise(slug: "stripe") { id } }

I'm seeing:

{
  "data": {"enterprise": null},
  "errors": [
    {
      "type": "FORBIDDEN",
      "path": ["enterprise"],
      "extensions": {"saml_failure": false},
      "locations": [{"line": 1, "column": 28}],
      "message": "Resource not accessible by integration"
    }
  ]
}

[jeffwilcox]

What permissions might you have? I'm able to call using the query I have above and these enterprise perms.

  restapi API graphql GraphQL POST +0ms
Enterprise "microsoftopensource" id: present
App has 1 installation(s):
  - target_type=Enterprise repository_selection=selected
    Granular permissions granted:
      enterprise_custom_properties: write
      enterprise_organization_installation_repositories: write
      enterprise_organization_installations: write
      enterprise_organizations: write
      enterprise_people: write
      enterprise_sso: write

[jeffwilcox]

Just mentioning in case others are kicking the tires... I'm able to call some of the highlighted people management mutations using a classic PAT with enterprise:admin permission, but not with the newer GitHub App installation on the GraphQL side. May be an underlying issue with how the permission checks are plumbed in public preview.

[hpsin]

Thanks, we're looking at expanding access here so that the fields and mutations available match permission expectations. We know we need to add some Enterprise Admin mutations to the enterprise people: write permission.

[schulmak]

Hello

I would like to automate the whole process of create ,install and manage the GitHub app.
I already tested the process and could not find a solution for automate the creation of the app since its need a interactive action from the user.
Is it planned that this will also be possible in the near future?

[schulmak]

@hpsin Thank you for the fast reply.
It’s good to know that the topic is familiar to you. Maybe you know this (not related to your release and you can close my question if you like) - is there a way to automate the creation of fine-grained tokens? I am searching for a way to automate the authentication for a third-party tool or many different users and different repositories. :)

[hpsin]

We don't support the automatic creation of fine-grained PATs. However, that's exactly the goal of GitHub Apps - they can mint tokens with the right permissions on them for the task you want to accomplish. You can scope them down to arbitrary repos and permissions using parameters during authentication - https://docs.github.com/en/apps/creating-github-apps/authenticating-with-a-github-app/generating-an-installation-access-token-for-a-github-app#generating-an-installation-access-token

[weshaggard]

@hpsin Using github apps I hit issues like https://github.com/orgs/community/discussions/24549, are there plans to try and address these gaps?

[hpsin]

Yes, we definitely want to support installing an app onto an enterprise and giving it permissions against all of the orgs and repos in the enterprise, and then following up with making that selective using org and repo custom properties (so i.e. "Install this app on the enterprise with access to all importance: medium orgs, and the language includes: java repos in them, with this set of org/repo permissions"). Then, a single installation token can manage all of the orgs and repos at once.

We don't have a date for this but it's a top priority for us. Keep na eye on the roadmap for an item about this.

[weshaggard]

Thanks. The primary scenario we were hitting was we couldn't create a PR from a private fork so hopefully forks of enterprise repos will be accessible from one of the tokens generated from a github app.

[jdesulme]

We'd like to use Enterprise Apps to access network configurations. This doesn't seem to be available yet either, but I would love to see it as well.
https://docs.github.com/en/enterprise-cloud@latest/rest/enterprise-admin/network-configurations?apiVersion=2022-11-28#list-hosted-compute-network-configurations-for-an-enterprise

[hpsin]

Thanks! We'll talk to the team about it.

[kylebyerly-hp]

I would like to be able to get the saml email <-> github mapping for my enterprise users. To do that for all users (and not just those with their email public), and to ensure it is the primary email from the idp I need to access the samlIdentityProvider.externalIdentities information.

query ($enterprise: String!, $endCursor: String) {
  enterprise(slug: $enterprise) {
    ownerInfo {
      samlIdentityProvider {
        externalIdentities(first: 100, after: $endCursor) {
          pageInfo {
            hasNextPage
            endCursor
          }
          edges {
            cursor
            node {
              samlIdentity {
                username
              }
              user {
                login
                url
                name
                createdAt
              }
            }
          }
        }
      }
    }
  }
}

[hpsin]

Thanks for the report - we've opened a workitem internally to look at this, because yes, this makes a lot of sense to have access to.

[strayer]

@hpsin Is there any news regarding this? We have a similar use-case that apparently doesn't seem to be possible yet.

[anttiharju]

Very much interested in this

[nadaoneal]

It's quite strange that this isn't yet supported - isn't the Venn diagram of companies that use Github Enterprise and companies that authenticate with SAML nearly a circle? Or if not, surely there's significant overlap.

[jackmtpt]

It seems like Entra ID SCIM integration is not supported yet via GitHub Apps. The documentation (https://learn.microsoft.com/en-gb/entra/identity/saas-apps/github-enterprise-managed-user-oidc-provisioning-tutorial#step-2-prepare-to-configure-provisioning-with-microsoft-entra-id) still talks about making a Classic PAT.

We want to disable classic PATs entirely but this is not possible until Entra ID can manage users via SCIM using an App installed at the enterprise level it seems.

[jeffwilcox]

Definitely with you there... +1, that's why we have to use this checkbox for fine-grained PATs with our EMU enterprise.

[francovp]

Hello. I need to assign users to billing cost-centers using Github App authentication with the API {{api_url}}/enterprises/{{enterprise}}/settings/billing/cost-centers/{{cost_center_id}}/resource, but I don't see any mention of "Billing" permissions in the "Enterprise permissions" section when creating an app. Is "Billing" related permissions still unsupported, or I'm missing something? If not, any idea when this will be enabled?

[spdaley]

Is there any plan to expose any of the ownerInfo attributes here? I see a similar comment above but we are looking at different attributes so figured I'd post this as well. We are trying to replace our PAT solution with a github app solution and these are the items we are currently querying:

query paginate($cursor: String) {
  enterprise(slug: "${this.gitHubEnterpiseName}") {
    ownerInfo {
      twoFactorRequiredSettingOrganizations(first: ${pageSize}, after: $cursor, value: ${isTwoFactorRequired}) {
        nodes {
          id
        }
        pageInfo {
          hasNextPage
          endCursor
        }
      }
    }
  }
}

In addition to twoFactorRequiredSettingOrganizations we are also trying to get access to the following other items under ownerInfo:

• samlIdentityProviderSettingOrganizations
• membersCanCreateRepositoriesSettingOrganizations
• defaultRepositoryPermissionSettingOrganizations
• membersCanDeleteRepositoriesSettingOrganizations

Right now, all of these just return a null ownerInfo value. They don't fail, it just comes back null.

Is there any plan to expose some more of this?
Thanks.

[RyanMissettSkipton]

We would love to see much wider support for GH Apps at the Enterprise level. It would drastically improve the situation for our management capabilities.

We would also be really happy to see the ability to use App Manifests to automate the installation and config at Enterprise level, similar to how it works at the Org level now.

[ES00660463]

Our billing team has several automated processes to query enterprise-level endpoints, allowing them to retrieve user licensing data and handle internal chargebacks across different departments. For this, they rely on the GET /enterprises/{enterprise}/consumed-licenses endpoint (documentation) to review which users are consuming specific license types.

Similarly, another department uses the GET / POST /enterprises/{enterprise}/settings/billing/budgets endpoints (documentation) to automate the creation of budgets and cost centers for our various business units.

Additionally, our IT team uses the GET /enterprises/{enterprise}/audit-log endpoint (documentation) to monitor security and audit user operations.

Currently, none of these endpoints are supported by either Fine-Grained PATs or GitHub Apps, leaving us with no other choice than using Classic PATs from administrator accounts.

These automation tasks are critical to our company's daily operations. From a security standpoint, our CISOs find it highly concerning that we are forced to generate personal tokens from admin users to perform these actions, given the inherent security risks involved.

Therefore, we request that GitHub App enterprise permissions be expanded to achieve full parity with Classic PATs, enabling us to cover these essential use cases securely.

[ebickle]

A couple things for the GitHub team:

1. APIs require case-sensitive repo names: Ran into a bug with the GitHub app installation APIs: the APIs to grant or revoke repository access to an app installation (the "selected repositories") is case-sensitive.We were normalizing repository names to lowercase to avoid duplicates; that caused some errors like this:

   data: {
     message: 'Repositories not found in this organization: appsec-github-APP. No change has been made to the installation.',
     documentation_url: 'https://docs.github.com/rest/enterprise-admin/organization-installations#grant-repository-access-to-an-organization-installation',
     status: '422'
   }
   

   All other GitHub APIs are case-insensitive, so this appears to be a mistake. Would be a huge help to have these be case-insensitive too! At the request of our GitHub account reps, I've created support ticket #4476848 for this issue.

2. GitHub app installations cannot have zero selected repositories: Could the APIs and GitHub UI be updated to allow a GitHub app installation to have zero repositories selected? We are using automation to grant or remove access; we want our administrative to pre-install GitHub apps with zero repositories selected, then have our automation grant or revoke repo-level access based on events (e.g. repo custom properties changing).

   Currently, we get errors when an installation has zero repositories - it requires us to have much more complex and fragile repository 'selection' logic. There are also some valid reasons to have zero repositories selected; for example, a third-party app we want to grant org-level read to (user list) but not any repo-level permissions.

[MichaMican]

We are using BYO GitHub accounts with SSO Identities linked and want to create an automated process that highlights users that are no longer with us.
For this we would like to query all users of the Enterprise with ExternalIdentity value, which currently is not supported by GitHub Apps for Enterprise.
This would be super helpfull for us to streamline and optimze the offboarding process.

[anttiharju]

I guess this thread covers you?

[MichaMican]

if i understand it correctly - yes :)

[granthouston44]

Posting on behalf of our GitHub Enterprise governance/platform team. We operate a GHE.com enterprise tenant and are trying to automate enterprise rulesets as code.

Adding another enterprise API gap/use case for prioritisation: Enterprise Rulesets API support for GitHub App authentication.

We are trying to automate GitHub Enterprise rulesets as code for governance/compliance purposes. Our intended model is:

• GitHub App installation tokens for Terraform/provider-backed GitHub administration where supported.
• API-backed automation for enterprise-level rulesets from reviewed JSON definitions.
• Avoid classic PATs/service-user tokens for high-privilege governance automation wherever a GitHub App can be used instead.

The enterprise rulesets REST API documentation currently lists GitHub App installation access tokens and GitHub App user access tokens as supported credential types for:

GET    /enterprises/{enterprise}/rulesets
POST   /enterprises/{enterprise}/rulesets
GET    /enterprises/{enterprise}/rulesets/{ruleset_id}
PUT    /enterprises/{enterprise}/rulesets/{ruleset_id}
DELETE /enterprises/{enterprise}/rulesets/{ruleset_id}

Docs reference:
https://docs.github.com/en/enterprise-cloud@latest/rest/enterprise-admin/rules?apiVersion=2026-03-10

However, these endpoints require:

enterprise_administration=write

and that permission is not currently available to grant to enterprise-owned GitHub Apps.

We tested both GitHub App auth models:

1. Enterprise GitHub App installation token

Calling:

GET /enterprises/{enterprise}/rulesets?per_page=1

returns:

HTTP 403
Resource not accessible by integration
x-accepted-github-permissions: enterprise_administration=write

2. GitHub App user access token

We authorised the GitHub App as an enterprise admin user. The user token itself is valid:

GET /user
HTTP 200

But calling the enterprise rulesets endpoint with the same GitHub App user token returns:

HTTP 403
Resource not accessible by integration
x-accepted-github-permissions: enterprise_administration=write
x-accepted-oauth-scopes: admin:enterprise

GitHub Support confirmed that enterprise_administration=write cannot currently be provisioned on an enterprise-owned GitHub App, and that the only supported non-interactive automation route for these endpoints today is a classic PAT with admin:enterprise, created by an enterprise owner.

That is workable as a temporary bridge, but it is not ideal for enterprise governance automation. Enterprise ruleset management is exactly the kind of high-privilege activity we would prefer to run through GitHub Apps for auditability, lifecycle management, and least-privilege access, rather than through a broad classic PAT on a service/admin account.

Request

Please prioritise support for granting:

enterprise_administration=write

or equivalent targeted enterprise ruleset permissions to enterprise-owned GitHub Apps.

This would unblock secure automation for:

• Managing enterprise rulesets as code.
• Applying consistent governance across multiple organizations.
• Avoiding classic PATs with admin:enterprise.
• Using GitHub App installation tokens or GitHub App user access tokens for enterprise-level governance workflows.
• Aligning the documented enterprise rulesets API auth model with permissions that can actually be granted to enterprise-owned GitHub Apps.

This is similar to the other comments in this thread around replacing classic PATs for enterprise-level automation. In our case, the specific blocker is enterprise ruleset management.

[lakshya-singh-glean]

Two critical things still missing:

• Third Party app installation at enterprise level
• REST API for enterprise members, graphql is a bad interface to work with for humans and agents. REST is much more simpler to navigate around

[jeffwilcox]

Ahh 3P install at the enterprise level, meaning across all orgs at once?

[lakshya-singh-glean]

not all orgs at once but enterprise installation of 3P github apps.