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:

• POST /repos/:owner/:repo/generate

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

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!

Enable or disable automated security fixes for a repository

Previously, you could only enable or disable automated security fixes from a repository's security alerts page. We understand that having to do this for a large amount of repositories is not an optimal user experience. We've heard your feedback and are pleased to announce that we have released a new set of endpoints to manage the automated security fixes setting for your repositories.

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

application/vnd.github.london-preview+json

The first endpoint allows you to enable the automated security fixes setting:

PUT /repos/:owner/:repo/automated-security-fixes

The second endpoint allows you to disable the automated security fixes setting:

DELETE /repos/:owner/:repo/automated-security-fixes

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!

Perform an "Update branch" on a pull request via the REST API

We are pleased to announce a new API for updating the branch on a pull request, the Update Branch API. Rather than having to manually click a button to update the HEAD of a pull request branch with the latest changes from the base branch, you can now do so with one REST API endpoint call.

Why not just use the Merging API? Good question, and of course you can! The advantage of using this new API is that you only need the pull request number, not the base or head. This could potentially save a few roundtrips to the API and reduce the risk of getting rate limited.

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

application/vnd.github.lydian-preview+json

The update a pull request branch endpoint allows you to update the HEAD of the pull request branch for a pull request.

PUT /repos/:owner/:repo/pulls/:pull_number/update-branch

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.

Feedback welcomed!

Enable or disable vulnerability alerts for a repository

Previously, you could only enable or disable repository vulnerability alerts by checking a box in a repository's settings. We understand that having to do this for a large amount of repositories is not an optimal user experience. We've heard your feedback and are pleased to announce that we have released a new set of endpoints to manage the vulnerability alerts setting for your repositories.

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

application/vnd.github.dorian-preview+json

The first endpoint allows you to enable the vulnerability alerts setting:

PUT /repos/:owner/:repo/vulnerability-alerts

And the second endpoint allows you to disable the vulnerability alerts setting:

DELETE /repos/:owner/:repo/vulnerability-alerts

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!

[Updated 06-10-19] You can also check whether repository alerts are enabled or disabled for a repository using a new endpoint.

  GET /repos/:owner/:repo/vulnerability-alerts

New webhook events and actions

Our webhooks team is pleased to announce that we have added some long-awaited webhook events and actions to the list that we support and they will be available today. You'll automatically begin receiving these events if you have a webhook that is subscribed to wildcard events, otherwise you will be able to select the new events from the list in your webhook settings. As always, we continue to recommend listening for the actions in order to future-proof your code.

Here are the new events and actions that we've added:

Please visit our webhooks documentation to view all of the events and actions that we support, and to get more information on these new ones.

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

List branches or pull requests for a commit (preview)

We're releasing a couple of REST endpoints that enable you to retrieve additional information from an existing commit.

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

application/vnd.github.groot-preview+json

The first endpoint allows you to get the list of branches where the given commit is the HEAD:

GET /repos/:owner/:repo/commits/:commit_sha/branches-where-head

The second one enables you to get a list of pull requests associated with the commit:

GET /repos/:owner/:repo/commits/:commit_sha/pulls

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!

Webhook IP addresses are changing

On April 9th, GitHub will begin sending webhooks from the 140.82.112.0/20 range of IP addresses in addition to the older 192.30.252.0/22 range.

We use a large pool of IP's to reach our customers, and we are adding further netblocks to help serve webhooks more reliably. If you have rules in place that only allow GitHub webhooks from our trusted addresses, you will need to update them.

This block of IPs has been in the /meta API endpoint since May 2018, but we wanted to announce this update in case you missed it.

Please contact us if you have any questions.

New response code for notifications marked as "read" in bulk

You can use the /PUT notifications endpoint to mark all notifcations as "read." Similarly, you can use the PUT /repos/:owner/:repo/notifications endpoint to mark all notifications as "read" for a specific repository.

Sometimes, GitHub would time out and return an error when there were too many unread notifications to process in a single request. We've changed both endpoints to trigger a background job that will mark the notifications as "read" asynchronously. If the operation is too expensive for a single request, the endpoint returns a 202 status code with the following response:

{
  "message": "Unread notifications couldn't be marked in a single request. Notifications are being marked as read in the background."
}

After analyzing recent request data and we expect very few requests to trigger a background job. Most requests should return a 205 status code as usual. If you do receive a 202 status code, it will take a short amount of time for all notifications to be marked as "read" in the background job. There is currently no way to check if the job has completed. Instead, we recommend checking the number of unread notifications in separate requests using one of these endpoints:

GET https://api.github.com/notifications?all=false

or

GET https://api.github.com/repos/:owner/:repo/notifications?all=false

Preview enable and disable Pages API endpoints

We're releasing a new Pages API preview that allows you to enable and disable GitHub Pages from the REST v3 API. These add to our existing Pages APIs which allow you to access & update Pages configuration as well as access & create new builds.

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

   application/vnd.github.switcheroo-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!