Issue Events API - Dismissed Review Event State

On January 17, 2018, we will introduce a breaking change to the dismissed_review event in the Issue Events API.

Currently, the REST API v3 passes an integer for state, but with this change it will pass a more informative string. Possible strings include commented, approved, or changes_requested. Along with this breaking change, the API will no longer include the dismissal_commit_id field if a commit was not involved in the dismissal.

Please update your code accordingly, and let us know if you have any questions or feedback!

Preview GraphQL API v4 Node IDs in REST API v3 resources

To help with migrating from our REST API v3 to GraphQL API v4, we're introducing a new preview period to include the GraphQL node ID in the response for the following REST API v3 resources:

• Deployments
• Gists
• Git Blobs
• Git Commits
• Git References
• Git Tags
• Issues
• Labels
• Milestones
• Organizations
• Projects
• Pull Requests
• Reactions
• Releases
• Repositories
• Statuses
• Teams
• Users

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

application/vnd.github.jean-grey-preview+json

Example response from Users which includes node_id:

{
  "id": 79995,
  "login": "dewski",
  "node_id": "MDQ6VXNlcjc5OTk1"
}

Fetching the same user using the node interface in our GraphQL API v4:

{
  node(id: "MDQ6VXNlcjc5OTk1") {
    ... on User {
      databaseId
      login
      id
    }
  }
}

Which would return:

{
  "data": {
    "node": {
      "databaseId": 79995,
      "login": "dewski",
      "id": "MDQ6VXNlcjc5OTk1"
    }
  }
}

For more information, see "GraphQL Global Relay IDs."

Please note that node_id is only available to GitHub Enterprise customers on 2.12 (and future GHE versions when they are released).

If you have any questions or feedback, please let us know on the GitHub Platform Forum.

Introducing new ways to build with GitHub Enterprise 2.12

Yesterday, we released GitHub Enterprise 2.12. This release includes a few updates relevant to the platform community including GitHub Apps, global webhooks, GitHub Enterprise version information in API responses, and new and improved documentation.

GitHub Apps compatibility

GitHub Apps is now enabled in early access for GitHub Enterprise 2.12. This means GitHub Apps can be created and installed on the GitHub Enterprise instance. We’re still customizing the GitHub Apps experience for the unique needs of an on-premise environment—hence the “early access”—and we’d appreciate your feedback along the way.

Global webhooks

In addition to Organization and Repository-specific webhooks, teams can now configure webhooks that are global to the entire instance of GitHub Enterprise. Global webhooks give administrators the ability to configure notifications for account creation and deletion, as well as membership changes. These events are also available to integrators, adding depth to any administrative features your integration offers. Check out help or the API documentation for more details.

Adding GitHub Enterprise version info to API responses

GitHub Enterprise 2.12 also returns the GitHub Enterprise version via the Meta API and response headers for all REST API endpoints.

Check out updated documentation

As part of the GitHub Apps release, you'll find refreshed documentation:

• A new guide for getting started with building apps.
• An updated guide that outlines the differences between GitHub Apps and OAuth Apps.
• A streamlined top navigation that makes Enterprise documentation accessible from any page.

We can’t wait to see what you’ll build with these new features. Learn more on the release blog.

If you have any questions about GitHub Apps, or want to collaborate with other integrators, check out the Platform Forum.

Deprecation of performed_via_integration key

As part of the name change from Integrations to GitHub Apps, we have deprecated the performed_via_integration key in favor of performed_via_github_app. The old key will no longer be returned starting on December 13. Please update your application to respond to the new key as soon as possible.

For related deprecations, please see our previous blog post.

Questions?

If you have questions about this upcoming deprecation, feel free to reach out on the Platform forum.

Ending the License API preview

In March of 2015, we announced the License API preview to support open source license usage on GitHub.com.

Since then, we've improved the underlying license detection algorithm, added license support to additional endpoints, and made it easier to retrieve a repository's license text.

Today, we're making things official by ending the preview period, and we consider the response payload to be stable going forward. We've also exposed license metadata via the GraphQL API as a repository's licenseInfo property.

Going forward, endpoints that return license metadata will no longer require passing the preview media type. Instead, we recommend that you specify v3 as the version in the Accept header:

application/vnd.github.v3+json

Please note, however, GitHub Enterprise versions that do not yet support the License API will still require the custom media type:

application/vnd.github.drax-preview+json

For more information, see the License API documentation or drop us a line!

Preview the new Repository Transfer API

We're releasing a new endpoint that allows you to transfer a repository to another user or organization.

New endpoint

• Transfer a repository

To access this new API endpoint during the preview period, you must provide a custom media type in the Accept header:

application/vnd.github.nightshade-preview+json

During the preview period, we may change aspects of this API endpoint 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!

Archiving repositories

As part of the release of archiving repositories, we've made changes to expose this feature to developers.

Note that archived repositories are read-only to everyone (including repository owners). This includes anyone using the REST or GraphQL APIs to edit the repository, issues, pull requests, labels, milestones, projects, wiki, releases, commits, tags, branches, reactions, or comments. No one (including repository owners) can use the REST or GraphQL APIs to create new issues, pull requests, or comments on an archived repository.

To our GitHub Enterprise customers: archiving repositories will be available in the next Enterprise release (2.12), but not in the current version or older versions.

REST API changes

• Repository responses now contain an archived field that is true or false depending on whether the repository was archived.
• You can use the REST API to archive repositories by passing the "archived": true parameter to the Edit endpoint at PATCH /repos/:owner/:repo.

GraphQL API changes

• Repository, RepositoryInfo, and RepositoryInvitationRepository objects now contain an isArchived field that is true or false depending on whether the repository was archived.

Webhook changes

• RepositoryEvent webhooks are now emitted when a repository is archived or unarchived.

Search changes

• You can search for archived repositories and their issues and pull requests using the archived:true search filter.

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

Deprecation reminder for certain GitHub Apps events, keys, and routing

As part of the name change from Integrations to GitHub Apps, we previously announced breaking changes to certain webhook events, payloads, responses, and URL routing. We continued to support the original implementation with a deprecation date of November 22, 2017. As this date nears, we want to remind you to update your applications as soon as possible.

API and webhook changes

As announced in May, the following breaking changes will be made to the API and webhooks on November 22:

• The integration_installation and integration_installation_repositories event names will be removed in favor of installation and installation_repositories.
• The integration_id key in webhook payloads and API responses will be removed in favor of the app_id key.

Changes to URL routing

As announced in July, URLs that reference "integration" or "integrations" will be removed entirely and the temporary redirection we've been performing will cease to function on November 22.

For example, a URL of https://github.com/integrations/super-ci/installations/new will no longer work. The correct format for that URL is https://github.com/apps/super-ci/installations/new.

Questions?

If you have questions about these upcoming deprecations, feel free to reach out on the Platform forum.

Additional endpoints available for GitHub Apps

As part of the ongoing audit of the availability of REST API endpoints for GitHub Apps, we've enabled another batch of endpoints.

Recently enabled endpoints

The newly enabled endpoints available now include:

• PUT /repos/:owner/:repo/import
• GET /repos/:owner/:repo/import
• PATCH /repos/:owner/:repo/import
• DELETE /repos/:owner/:repo/import
• GET /repos/:owner/:repo/import/authors
• PATCH /repos/:owner/:repo/import/authors/:author_id
• GET /repos/:owner/:repo/import/large_files
• PATCH /repos/:owner/:repo/import/lfs
• GET /repos/:owner/:repo/events
• GET /orgs/:org/outside_collaborators
• DELETE /orgs/:org/outside_collaborators/:user
• PUT /orgs/:org/outside_collaborators/:user
• GET /feeds
• POST /markdown
• POST /markdown/raw
• GET /meta
• GET /repos/:owner/:repo/issues/:issue_number/timeline
• GET /users/:username/repos

Additionally, the following endpoints are now available for user-to-server requests:

• PUT /repos/:owner/:repo/import
• PATCH /repos/:owner/:repo/import
• DELETE /repos/:owner/:repo/import
• PATCH /repos/:owner/:repo/import/authors/:author_id
• PATCH /repos/:owner/:repo/import/lfs
• POST /repos/:owner/:repo/commits/:sha/comments
• PATCH /repos/:owner/:repo/comments/:id
• DELETE /repos/:owner/:repo/comments/:id
• POST /orgs/:org/repos
• POST /user/repos
• GET /repos/:owner/:repo/teams
• DELETE /repos/:owner/:repo/issues/comments/:id
• PATCH /repos/:owner/:repo/issues/comments/:id
• DELETE /repos/:owner/:repo/issues/:number/assignees
• POST /repos/:owner/:repo/issues/:number/assignees
• PUT /repos/:owner/:repo/issues/:number/lock
• DELETE /repos/:owner/:repo/issues/:number/lock
• DELETE /repos/:owner/:repo/issues/:id/labels
• PUT /repos/:owner/:repo/issues/:id/labels
• DELETE /repos/:owner/:repo/issues/:id/labels/(.*?)
• POST /repos/:owner/:repo/labels
• DELETE /repos/:owner/:repo/labels/(.*?)
• PATCH /repos/:owner/:repo/labels/(.*?)
• DELETE /orgs/:org/outside_collaborators/:user
• PUT /orgs/:org/outside_collaborators/:user
• GET /feeds
• POST /repos/:owner/:repo/comments/:id/reactions
• POST /repos/:owner/:repo/issues/:number/reactions
• POST /repos/:owner/:repo/issues/comments/:id/reactions
• GET /repos/:owner/:repo/pulls/comments/:id/reactions
• POST /repos/:owner/:repo/pulls/comments/:id/reactions
• DELETE /reactions/:id
• PUT /repositories/:repository_id/collaborators/:username
• DELETE /repositories/:repository_id/collaborators/:username
• DELETE /repos/:owner/:repo
• PATCH /repos/:owner/:repo
• POST /repos/:owner/:repo/merges

How can I try it?

To access this functionality, you’ll need to provide the following custom media type in the Accept header:

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

What about other endpoints?

We're actively working on enabling more endpoints. Check back on the developer blog for updates when new batches become available. If you have specific requests or feedback, come chat with us in the Platform forum.

Nested Teams API Preview has new privacy defaults

Today we're releasing a change to the Nested Teams API Preview: the default privacy when creating a nested team is now closed.

How can I try it?

To access the Nested Teams APIs during the preview period, you must provide a custom media type in the Accept header:

application/vnd.github.hellcat-preview+json

Give us your feedback

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