API changes for Multiple Issue Assignees

GitHub recently added the ability to assign up to ten people to issues. We're updating Issue payloads and adding a couple new endpoints to help you build apps. You can enable these changes during the preview period by providing a custom media type in the Accept header:

application/vnd.github.cerberus-preview

For example:

curl "https://api.github.com/repos/github/hubot/issues" \
  -H 'Authorization: token TOKEN' \
  -H "Accept: application/vnd.github.cerberus-preview" \

The issues returned in this list will include the new assignees key.

You can learn more about the new responses and endpoints in the updated Issues and Issue Assignees documentation

Preview the Timeline API

We've added an API for issue timelines, which will let you fetch a list of events from an issue or pull request timeline.

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

application/vnd.github.mockingbird-preview

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

Preview support for Reactions API

GitHub recently added Reactions to Pull Requests, Issues, and Comments to help people express their feelings more simply and effectively in conversations. We are adding endpoints for Reactions so that you can now react and unreact via the API. You can enable these changes during the preview period by providing a custom media type in the Accept header:

application/vnd.github.squirrel-girl-preview

For example:

To view reactions on an issue:

curl "https://api.github.com/repos/github/hubot/issues/1/reactions" \
  -H "Accept: application/vnd.github.squirrel-girl-preview"

You can learn more about the new reaction response objects in the updated Commit comment, Issue, Issue comment, and Review Comment documentation. There is also new Reaction documentation.

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

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

Source Import API enhancements for working with Git LFS

Today we're introducing enhancements to the Source Import API to support importing repositories with files larger than 100MB.

Changes to parameters for starting an import

Starting an import no longer requires a vcs parameter. Please be aware that without this parameter, the import job will take additional time to detect the vcs type before beginning the import. This detection step will be reflected in the response.

New methods

We've added 3 new methods that will enable API consumers to:

• update the authentication or project choice for an import. If no parameters are provided during the request, the import will be restarted. Please note that this is a breaking change. Updating authentication for the originating URL is no longer supported through the start an import method. Please update your applications to use the new method.

• set their preference for using Git LFS to import files larger than 100MB.

• list all the files larger than 100MB that were found during the import.

New attributes for Git LFS

Several new response attributes (use_lfs, has_large_files, large_files_size, large_files) were added to provide details regarding the large files found during the import. You can read more about the attributes here.

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

application/vnd.github.barred-rock-preview

For more information, see the Source Import API documentation, and if you have any questions or feedback, please let us know.

Preview support for OAuth authorizations grants API

GitHub recently made changes to the application authorizations settings screen within GitHub to display one entry for each OAuth application a user has authorized. Previously this screen showed one entry for each OAuth token that was generated by an OAuth application. For example, if you installed two instances of GitHub Desktop, you would see one entry for each installation. To simplify OAuth application management, we now show a single entry for each OAuth application. For OAuth applications that use the web flow this was not a problem, since the web flow never generates more than one token for a given OAuth application and user. However, going forward, GitHub would like to allow all OAuth applications, including those that use the web flow, to generate more than one token.

In preparation for that change, we are adding API support to simplify management of OAuth applications that matches what is available on GitHub.com. You can enable these changes during the preview period by providing a custom media type in the Accept header:

application/vnd.github.damage-preview

For example:

curl -u username "https://api.github.com/applications/grants" \
  -H "Accept: application/vnd.github.damage-preview"

You can learn more about the new APIs in the OAuth authorizations documentation.

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

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

New webhook event actions are now live

As promised last month, we've expanded several webhook events with new functionality. Webhook events involving repositories, issues, and comments have all been updated to include new actions.

Repository events will now fire when a repository is deleted, made public, or made private. In addition, while repository creation events will still only fire for organizations, the new repository event actions can be delivered for user-owned repositories.

Events for issues, pull requests, and comments have also been updated and will now fire when these objects are edited or deleted. When an issue, pull request, or a comment has been edited, the event's payload will include a "changes" object. For example, if you've updated the title and body of an issue, the webhook payload informs you of what the issue used to look like:

{
  "action": "edited",
  "changes": {
    "title": { "from": "This is the old title." },
    "body": { "from": "This is the old body." }
  },
  "issue": {
    "title": "This is the new title.",
    "body": "This is the new body."
  }
}

The new values will be present in the issue object itself, as detailed above. Unchanged values will not be present within the changes object. Comment edits follow a similar pattern, though because they have no titles, the only change included in the payload would be the comment's body.

List of comprehensive changes

New actions were added to five events, all of which are detailed below.

RepositoryEvent

• deleted: sent when a user-owned or organization-owned repository is deleted.
• publicized: sent when a user-owned or organization-owned repository is switched from private to public.
• privatized: sent when a user-owned or organization-owned repository is switched from public to private.

IssuesEvent

• edited: sent when the title and/or body of an issue is edited.

IssueCommentEvent

• edited: sent when a comment on an issue or pull request is edited
• deleted: sent when a comment on an issue or pull request is deleted

PullRequestEvent

• edited: sent when the title and/or body of a pull request is edited.

PullRequestReviewCommentEvent

• edited: sent when a comment on a pull request's unified diff (in the Files Changed tab) is edited
• deleted: sent when a comment on a pull request's unified diff (in the Files Changed tab) is deleted

Take a look at the documentation for full details. If you have any questions or feedback, please get in touch.

Commit Reference SHA-1 API is now official

We're making the Commit Reference SHA-1 API part of the official GitHub API.

During the preview period you needed to provide the application/vnd.github.chitauri-preview+sha preview media type in the Accept header to opt-in to the changes. Now that the preview period has ended the custom media type has changed to application/vnd.github.v3.sha (but the preview type will continue to work).

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

Deployment and DeploymentStatus API enhancements preview period

We've expanded our Deployments APIs to accommodate more powerful deployment practices and to lay the foundation for a more seamless integration of deployments within GitHub.

Link to a live deployment

To enable easy access to a live version of a deployment, we've added an environment_url field to the Deployments API. This environment will be exposed as a link in the Pull Request timeline to enable users to directly access a running version of their code without leaving the context of their work.

Note: To add some clarity, we've renamed the target_url field to log_url. We will continue accept target_url to support legacy uses, but we recommend modifying this to the new name to avoid confusion. Future API versions might not support target_url.

Inactive deployment status

We recognize that deployments in many common practices don't last forever. So, we've added a new inactive state to Deployment Statuses. You can use this state to communicate that a deployment is no longer active (e.g. something different has been deployed to the environment or the environment has been destroyed).

More information about environments

We've expanded our Deployments API to provide additional information about the environments associated with deployments.

We've added a new transient_environment field to allow you to communicate that an environment is specific to a deployment and will no longer exist at some point in the future (e.g. a temporary testing environment like a Heroku Review App). By pairing this with other additions, we can determine that an inactive deployment associated with a transient_environment has an environment_url that is no longer accessible.

Similarly, we've added a new production_environment field to allow you to communicate that an environment is one with which end users directly interact. We automatically set production_environment to true if the value for environment is "production".

Automatic creation of inactive statuses

Each time we receive a new successful deployment status, we automatically add a new inactive status to all previous deployments made within the relevant repository to the same environment (based on the value of environment) given the environment is both non-transient and non-production. You can opt out of this behavior by passing false with the new auto_inactive parameter.

For example, if feature-branch within https://github.com/user/repository is deployed to an environment named staging (which is a non-transient, non-production environment) and bugfix-branch within https://github.com/user/repository is later deployed to an environment named staging, we would automatically create a new inactive status for the deployment associated with feature-branch.

How can I try it?

Starting today, these API enhancements are available for developers to preview. At the end of the preview period, these enhancements will become official components of the GitHub API.

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

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

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

Take a look at the documentation for full details. We would love to hear your thoughts on these enhancements. If you have any questions or feedback, please get in touch with us!

Preview support for Git signing

GitHub recently started verifying GPG signed commits and tags. We are adding API support for signature verification and user GPG key management as well. You can enable these changes during the preview period by providing a custom media type in the Accept header:

application/vnd.github.cryptographer-preview

For example:

curl "https://api.github.com/user/gpg_keys" \
  -H 'Authorization: token TOKEN' \
  -H "Accept: application/vnd.github.cryptographer-preview" \

You can learn more about the new signature verification response objects in the updated repository commit, Git commit, and Git tag documentation. There is also new GPG key management documentation.

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

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

Preview Squash Support for the Pull Request Merge API

With the recent addition of squashing Pull Requests via the merge button, we're adding support to squash Pull Requests in the API as well. You can squash a pull request in the Pull Request Merge API during the preview period by providing a custom media type in the Accept header:

application/vnd.github.polaris-preview

For example:

curl "https://api.github.com/repos/github/hubot/pulls/123/merge" \
  -XPUT \
  -H 'Authorization: token TOKEN' \
  -H "Accept: application/vnd.github.polaris-preview" \
  -d '{
    "squash": true,
    "commit_title": "Never tell me the odds"
  }'

During the preview period, we may change aspects of these API methods based on developer feedback. We will announce the changes here on the developer blog, but we will not provide advance notice.

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