Introducing the "Managing enterprise accounts" GraphQL API

Now you can manage your enterprise account using the GraphQL API, which efficiently returns just the data you request. This API is designed to handle all of your enterprise account management needs, from monitoring account settings, access changes, and users within your enterprise. The Managing Enterprise Accounts API is available for GitHub Enterprise Cloud and for GitHub Enterprise Server.

For more information, see "Managing enterprise accounts."

Deprecated APIs and authentication

We are announcing deprecations that will improve the security of GitHub apps and APIs. We will provide more information during the following few months, including the exact timeline for discontinuing the support of these deprecations.

Authenticating using passwords

GitHub is deprecating password authentication to the API. Instead of using password authentication, create a personal access token using your Personal access tokens settings page in limited situations like testing. You should authenticate apps in production by using the web applications flow. For more information, see "Authorizing OAuth Apps."

Authenticating using query parameters

GitHub is deprecating authentication to the GitHub API using query parameters, such as using a token query parameter for OAuth user authentication or a client_id/client_secret query parameter for OAuth application authentication. All authentication to the GitHub API should be done using HTTP basic authentication.

Authenticating with SAML organizations

Apps must use the web application flow to obtain OAuth tokens that work with GitHub SAML organizations. OAuth tokens created using the Authorizations API are unable to access resources for GitHub SAML organizations.

Deprecating and adding endpoints for the OAuth Authorizations and OAuth Applications APIs

GitHub is deprecating the Authorizations API, which includes these endpoints:

Some client-side integrations use the deprecated Authorizations API to create personal access tokens and OAuth access tokens. These tokens must now be created using our web application flow. When appropriate, personal access tokens can still be created by the user on the Personal access tokens page. However, most integrations should register themselves as an OAuth application and use the web application flow to obtain an OAuth access token.

GitHub has replaced several deprecated endpoints with new ones. You can now find both the deprecated and new endpoints in the OAuth Applications API. Specifically, we have deprecated OAuth Applications API endpoints containing an OAuth token as a path parameter:

These new endpoints replace the deprecated endpoints:

Updating command-line utilities to use localhost-based redirect URLs

Command-line tools now support a web-based flow by using localhost-based redirect URLs and specifying a port. We have extended our support for localhost-based redirect URLs to securely improve the experience of command-line utilities for client-side integrations. Historically these tools have relied on the Authorizations API, and they have not been able to easily register an OAuth URL callback to use with our OAuth web application flow. Please see our documentation on redirect URLs for more information.

If you have any questions or feedback, please let us know!

List GitHub App installations for an organization

Now as an organization owner, you can list all GitHub App installations for an organization using the REST API. You must be an organization owner with admin:read scope to use this endpoint. The installation count includes all GitHub Apps installed on repositories in the organization.

GET /orgs/:org/installations

To list all GitHub App installations for an organization, you must provide the machine-man custom media type in the Accept header:

application/vnd.github.machine-man-preview+json

During the preview period, we may change aspects of these APIs based on developer feedback.

If we do, we will announce the changes here on the developer blog, but we will not provide any advance notice. If you have any questions or feedback, let us know.

GitHub Pages features become an official part of the REST API

The features that are a part of the GitHub Pages mister-fantastic-preview are now available on GitHub.com and will be available in the next versions of GitHub Enterprise (2.19 and higher). You will no longer need to pass a preview header to use most GitHub Pages API endpoints.

Preview media type no longer needed

Now that the preview period has ended (first announced in July 2016), you no longer need to pass the mister-fantastic-preview custom media type. Instead, we recommend that you specify v3 as the version in the Accept header:

application/vnd.github.v3+json

Please note that if you use GitHub Enterprise versions 2.8 to 2.18, you will still need to provide this custom media type in the Accept header:

application/vnd.github.mister-fantastic-preview+json

Onward! Thanks again to everyone that tried out these GitHub Pages API features during the preview period.

Multi-line comments

Now you can create comments across multiple lines of code in a pull request diff using REST API or GraphQL.

To create multi-line comments or see multi-line comments with the new supported fields when you fetch comment responses, you must provide a custom media type in the Accept header:

application/vnd.github.comfort-fade-preview+json

During the preview period, we may change aspects of these APIs based on developer feedback.

If we do, we will announce the changes here on the developer blog, but we will not provide any advance notice. If you have any questions or feedback, please let us know.

Team sychronization become an official part of REST API

The features that are a part of the team sychronization team-sync-preview are now available on GitHub.com. Going forward, the Team synchronization API endpoints will be available without a preview header.

Preview media type no longer needed

Now that the preview period has ended (first announced in June 2019), you no longer need to pass the team-sync-preview custom media type.

More check annotations are now shown on the "Files changed" tab

In May of 2018, we announced the Checks API, which added many new capabilities for running checks on code. One of those new capabilities were check annotations, which let apps annotate specific lines of code as part of a check run.

demo-screenshot-of-unchanged-files-with-check-annotations

Check annotations point directly to those lines where a test failure or a lint error occurred, and they empower users to fix any kind of errors or warnings quickly so they can move forward with their pull requests.

demo-screenshot-from-checks-api-blog-post

Today we're making check annotations even more powerful by bringing more of them to where you're already looking: the "Files changed" tab. Checks annotations created on lines or files that were not modified as part of a pull request will now be prominently displayed alongside the diff.

Internal testing has proven that surfacing unchanged files with check annotations has been especially beneficial to our workflows, because test failures can often happen on files that weren't modified as part of a pull request.

Click here to see it in action!

The best part? The API for creating check annotations has not changed. If you're already creating annotations on files or lines outside of the diff, then there's no need to modify any code to use this improvement.

If you have any questions or feedback, please let us know.

Grant GitHub Apps push access to protected branches

The Protected Branches API now allows you to grant GitHub Apps push access to protected branches.

You can only grant GitHub Apps push access to a protected branch if they have been installed with the repository contents write permission.

The Protected Branches API now includes the following endpoints:

The existing endpoint to set branch protection now accepts app restrictions:

If you have any questions or feedback, please get in touch!

Create and use repository templates

Repository templates enable you to create a new repository using an existing one that is marked is_template. This only copies repository contents without copying the commit history.

To access the new API, you must provide a custom media type in the Accept header:

application/vnd.github.baptiste-preview+json

The following new endpoint is available for you to generate a new repository from a template repository:

In addition, you can make your repository available as a template when you Create or Edit the repository. You can also GET a repository's information to see if the repository is available to use as a template (is_template key is true) or was generated from a template_repository. For more information, see the Repositories API.

During the preview period, we may change aspects of these APIs based on developer feedback. If we do, we will announce the changes here on the developer blog, but we will not provide any advance notice.

If you have any questions or feedback, please let us know!

Connect GitHub teams and IdP groups

Team synchronization is available for organizations using GitHub Enterprise Cloud. For more information, see GitHub's products in the GitHub Help documentation.

The Team Synchronization API allows you to manage connections between GitHub teams and external identity provider (IdP) groups.

You can manage GitHub team members through your IdP with team synchronization. Team synchronization must be enabled to use the Team Synchronization API. For more information, see "Synchronizing teams between your identity provider and GitHub" in the GitHub Help documentation.

To access the new API, you will need to authorize your API token for use with your IdP (SSO) provider. You must also provide a custom media type in the Accept header:

application/vnd.github.team-sync-preview+json

The following endpoints in the Team Synchronization API are available for you to use:

  • GET /orgs/:org/team-sync/groups
  • GET /teams/:team_id/team-sync/group-mappings
  • PATCH /teams/:team_id/team-sync/group-mappings

During the preview period, we may change aspects of these APIs based on developer feedback. If we do, we will announce the changes here on the developer blog, but we will not provide any advance notice.

If you have any questions or feedback, please let us know!