api

Subscribe to all “api” posts via RSS or follow GitHub Changelog on Twitter to stay updated on everything we ship.

~ cd github-changelog
~/github-changelog|main git log main
showing all changes successfully

GitHub upgraded its OpenAPI description to the OpenAPI Specification (OAS) 3.1.

Upgrading to OAS 3.1 will enable us to add GitHub Webhooks to the description, simplify the description of nullable schemas, and reduce the description size by removing duplicate nullable reference schemas.

The GitHub OpenAPI description contains more than 600 operations exposed in our API. For visual exploration of the API, you can load the description as a Postman Collection. Programmatically, the description can be used to generate mock servers, test suites, and bindings for languages not supported by Octokit.

The description is provided under two formats. The bundled version is preferred for most use cases as it makes use of OpenAPI components for reuse and readability. For tooling that doesn't support inline references to components, we also provide a fully dereferenced version.

We are currently still publishing the 3.0 version of the description, which is now generally available in the latest release. The 3.1 version of the description is being published in parallel and can be found in the descriptions-next folder in the github/rest-api-description repository. More information about GitHub's OpenAPI description can also be found in our documentation.

See more

We have released improvements to the code scanning API:

  • We've added the fixed_at timestamp to alerts. This is the first time that the alert was not detected in an analysis. You can use this data to better understand when code scanning alerts are being fixed.
  • We've enabled sorting of alert results using sort and direction on either created, updated or number. Use this to see the alerts that are most important to you first. For more information, see List code scanning alerts for a repository.
  • We've added a Last-Modified header to the alerts and alert endpoint response. For more information, see Last-Modified in the Mozilla documentation.
  • We've added relatedLocations to the SARIF response when you request a code scanning analysis. The field may contain locations which are not the primary location of the alert. See an example in the SARIF spec and read about getting a code scanning analysis for a repository.
  • We've added help and tags data to the webhook response alert rule object. For more information, see Code scanning alert webhooks events and payloads.
  • PATs with the public_repo scope now have write access for code scanning endpoints on public repos, if the user has permission. This is a bug fix and is now inline with the documentation.

For more information, see the Code scanning in the API reference.

See more

GitHub recently introduced the ability to set an expiration date when creating or regenerating a personal access token (PAT). For a PAT that is authorized to access an organization protected by SAML single sign-on (SSO), the expiration date of that PAT is now available via the GET /orgs/{org}/credential-authorizations API.

Organization administrators can use the following gh command to see the expiration dates of all PATs that are authorized to access their org by authenticating with a PAT that has the read:org scope:

gh api --paginate /orgs/:org/credential-authorizations --jq='.[] | [.authorized_credential_expires_at]'

Learn more about authorizing a personal access token for use with SAML single sign-on.

See more

GitHub Codespaces allows teams and organizations to spin-up developer environments directly from a browser or through Visual Studio Code, without the hassle of setting up a brand new environment tailored to a specific repository.

We've been hard at work since our general availability announcement in August making Codespaces the best way for you to develop software, which is why we're so happy to announce several new features at GitHub Universe 2021.

We know that many developers use the gh CLI to speed up or fully automate daily tasks, and we've received dozens of requests to add Codespaces support to the CLI. As of today, the gh codespace (or gh cs for those saving keystrokes) command now allows developers to manage their codespaces from the GitHub CLI. In addition to codespace creation, listing, and starting/stopping, users can forward ports, set port visibility, SSH into their codespaces, and copy files to/from their codespaces.

# Create a new codespace via the CLI
gh codespace create --repo monalisa/octocat --branch main

We're especially excited about ssh access, as it allows developers who prefer to use editors like vim and emacs to more easily develop in Codespaces. Just gh cs ssh into your codespace and launch your editor of choice; we'll set up the environment and grab all your dotfiles so you're ready to develop in seconds.

# SSH into the codespace created above
gh codespace ssh -c monalisa-monalisa-octocat-1337h4x0r

Complimenting the CLI, we are also launching an API in beta. The API provides control plane operations around a user's codespaces including creating, starting/stopping, listing available machine types, and setting user secrets. These APIs will allow developers to build Codespaces integrations into their favorite editors and tools, as well as allow for additional automation around Codespaces.

# Stop a running codespace via the API
curl https://api.github.com/user/codespaces/monalisa-monalisa-octocat-1337h4x0r/stop \
  -H "Authorization: token <Personal Access Token>" \
  -X POST

We also know that security and privacy are critical, and we've gotten a lot of feedback on providing additional visibility options for forwarded ports beyond public and private. Today we're launching a third option: org visible ports, which are accessible to any user in the organization the codespace has been created in. This is great for securely collaborating with your teammates on new and exciting features in your codespaces.

# Make port 80 visible to all users in an org
gh codespace ports visibility 80:org -c monalisa-monalisa-octocat-1337h4x0r

Continuing with security improvements, we have also heard from developers having difficulty launching codespaces from devcontainers stored in private container registries. To make this easier, we are offering streamlined access to containers stored in the GitHub Container Registry; you no longer have to provide a Personal Access Token (PAT).

Speaking of devcontainers, we know that there's a wide gap between using a predefined devcontainer and building a custom devcontainer. To help make that transition a little easier, we're launching the ability to extend devcontainers with features, which include shells, package managers, programming languages, and other common tools. For example, adding Terraform to a supported base image is as easy as adding the following to your devcontainer.json.

"features": {
  "terraform": "latest"
}

If you have any feedback about these features, or Codespaces in general, we'd love to hear from you!

Learn more about all our newly released features:

See more

Organizations using GitHub Enterprise Cloud now have more granular control over the repository access permissions they can grant to users, with custom repository roles – now available in Beta.

A custom repository role is created by an organization owner, and is available across all repositories in that organization. Each role can be given a custom name, and a description. It can be configured from a set of over 40 fine grained permissions. Once created, repository admins can assign a custom role to any user, team or outside collaborator in their repository.

Custom repository roles can be created, viewed, edited and deleted via the new Repository roles tab in Organization settings.

Screenshot 2021-10-25 at 12 59 46 PM

Custom repository roles are also fully supported in the GitHub REST APIs. The Organizations API can be used to list all custom repository roles in an organization, and the existing APIs for granting repository access to individuals and teams have been extended to support custom repository roles.

To get started with custom repository roles, read the docs.

See more

We have graduated twenty-three of the twenty-five existing previews that were in our REST API.

Previously, REST API consumers needed to pass in a custom media-type via an HTTP accept header (example: Accept: application/vnd.github.ant-man-preview+json) with requests to get additional response fields or to be able to access specific endpoints.

The following are REST APIs that still require the accept header:

  • content_references (corsair preview) application/vnd.github.corsair-preview+json

  • code_of_conduct (scarlet-witch preview) application/vnd.github.scarlet-witch-preview+json

The header is no longer needed for the other twenty-three REST API previews that have been graduated.

For the remaining two previews the plan is to sunset the previews later this year. We are actively reaching out to any consumers of the REST APIs of those previews.

See more

You can now set whether a repository allows forking when creating or updating it using either the REST or GraphQL API.

Previously, APIs for creating and updating repositories didn't consider the fields allow_forking (REST) or forkingAllowed (GraphQL). Now, this field can be set before invoking the API to configure whether a repository allows forking.

For reference, see documentation for the REST API and GraphQL API.

See more

The Codes of Conduct API preview, which was accessible with the scarlet-witch-preview header, is being deprecated.

On December 6th, 2021, the fields behind this API preview will no longer be accessible. We recommend using the Get community profile metrics endpoint to retrieve information about a repository's code of conduct.

Email notifications will be sent to active users of the API preview throughout the deprecation period.

If you have any questions, please contact GitHub Support.

See more

GitHub will stop supporting API Authentication via Query Parameters with Actions on October 6th 2021 at 14:00 UTC. If you are passing credentials via query or path parameters, GitHub will respond with client errors. Please refer to this blog post for details on authenticating API requests to GitHub using the Authorization header.

Removal

  • October 6 2021 at 14:00 UTC
See more

The new GraphQL mutation createCommitOnBranch makes it easier to add, update, and delete files in a branch of a repository.

This new API offers a simpler way to commit changes compared to the existing Git database REST APIs. With the new createCommitOnBranch mutation, you do not need to manually create blobs and trees before creating the commit. This allows you to add, update, or delete multiple files in a single API call.

Commits authored using the new API are automatically GPG signed and are marked as verified in the GitHub UI. GitHub Apps can use the mutation to author commits directly or on behalf of users.


See the GraphQL API reference for more information on using createCommitOnBranch. You can also try it in the GraphQL API Explorer! If you need a refresher on how to use the GraphQL API, see our guide.

See more

As previously announced, on September 8th 2021 at 14:00 UTC, GitHub will stop supporting API Authentication via Query Parameters.

If you are passing credentials via query or path parameters, GitHub will respond with client errors. Please refer to this blog post for details on authenticating API requests to GitHub using the Authorization header.

Removal

  • September 8 2021 at 14:00 UTC

Please check the latest Enterprise release notes to learn in which version API Authentication via Query Parameters will be removed.

See more