Preview the new Nested Teams APIs

We're releasing new endpoints and changes to existing endpoints to better help you administer your organization's nested teams.

New endpoints

Changes to existing API endpoints

  • The List team members and Get team membership endpoints will now include both direct and child team members.

  • The List team repositories and Check if a team manages a repository endpoints now include both direct and inherited repositories.

  • You can now create a team with a parent team by passing the parent_team_id parameter to the Create team endpoint.

  • You can now update a team's parent team by passing the parent_team_id parameter to the Edit team endpoint.

  • Deleting a nested team through the Delete team endpoint will delete the team and all its child teams. Note: this action is only available to organization admins.

  • Listing a repository's collaborators through the Lists collaborators will now include child team members.

  • Endpoints that return team hashes will now include the parent field representing the parent team. Additionally, the members_count and repositories_count will include all members and repositories according to the nested structure.

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


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!

Repository Invitations API is now official

The Repository Invitations API is now part of the official GitHub API. You will no longer be able to directly add a user to a repository. Instead, the user will receive an invitation, which they can accept or decline via email, notification, or API endpoint.

For details on how to use the repository invitations endpoints, please refer to the API documentation.

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

Helium and GitHub partner to streamline connected hardware development

Mark Phillips is Helium's Director of Customer Success.

In the coming weeks, we're excited to make it easier for IoT developers to prototype and ship connected devices as part of our new partnership with GitHub, and the GitHub Developer Program.

This means two things for the GitHub community:

  1. You can look forward to us integrating several parts of the Helium platform and features with the GitHub API, so you'll have a smoother experience when building IoT hardware and sensors.

  2. Starting today, all GitHub Developer Program members can access discounts on Helium products, cloud services, and ongoing support to get started.

Why Helium and GitHub?

Hardware and IoT developers already use GitHub as a core part of their workflows. Arduino and Raspberry Pi are a couple of hardware platforms that use GitHub for their open source development and community building. Similarly, the Helium Team depends on GitHub for our growing suite of open source IoT development tools.

We firmly believe that Helium, and our combination of hardware and software, is the best way for developers to protoype and deploy connected, secure hardware products. Now we're going to make it even better by removing as much friction as possible for GitHub users who are building applications with a wireless component. Our partnership will make it easier for you to access IoT development services and move faster when you're prototyping.

Helium and GitHub integration roadmap

Our current integration roadmap currently has two components, and it will likely expand as we collect your feedback.

GitHub authentication for the Helium Dashboard

We'll deliver the ability to create accounts and log in to the Helium Dashboard using your existing GitHub account. We'll also make it possible to automatically mirror your GitHub Team structure within the Helium Dashboard.

git push to deploy device configurations updates over the air

Few platforms make it possible to deploy configuration or complete software updates over the air to connected sensors. We'll offer developers the ability to git push updates to a target repository that will then kick off an OTA deployment to devices deployed in the field.

Helium for GitHub Developer Program members

To help Developer Program members get started, we're offering all of these discounts on Helium products:

Just use code HELIUM-AND-GITHUB-4-IOT during checkout.

All current members of the GitHub Developer Program received an email with details about how to buy Helium products with these discounts. If you're not yet a member of the GitHub Developer Program, you can apply here.

We can't wait to see what you build with GitHub and Helium. If you have any questions about our partnership or products, find us in the Helium Community Slack, post a message on the Helium Developer Forum, or send me a note.

Breaking changes to creating webhooks via the API

An urgent fix was released today related to creating and editing webhooks for repositories and organizations. Before today, if an existing webhook was modified to accept an event that did not exist, the REST API would respond with a status code of 200 and all of the configuration settings would be wiped out.

This issue affected the following endpoints:

As of around 12:30PM EST today, if you pass an invalid event as part of the events array input to one of those endpoints, the REST API will respond with a 422 status code. A full list of valid events can be found on this page.

Prior to this fix, the REST API accepted webhook events that no longer exist. Those events were:

The API has not allowed new webhooks to be created with these events since September 2013. If your webhooks are being created or edited to accept these events, they too will now begin responding with a 422 status code.

Normally, we provide several months' advance notice before making changes to our API, but because of the security implications, we pushed this out as soon as possible. We have not noticed an increase of 422s as a result, but we apologize for any inconvenience this may cause.

Preview team review requests API

We're excited to announce a new preview period for the Review Requests API to add, delete, and fetch team review requests.

To access information about team-based review requests during the preview period, you must provide a custom media type in the Accept header:


Breaking changes

In order for us to better support the various different types of review requests, we're modifying the /repos/:owner/:repo/pulls/:number/requested_reviewers payload structure to include both teams and users when this API graduates from preview later this year. Stay tuned for announcements on when this change will take place.

Going forward, when you GET this endpoint, it will return both users and teams in a hash syntax instead of only users. (You can get this response right now if you pass the preview header.) Please update your code accordingly.

During the preview period, we may change aspects of these API methods based on your feedback. If we do, we'll announce the changes here on the developer blog, but we won't provide advance notice.

If you have any questions or feedback, please contact us.

Upcoming routing changes for GitHub Apps (formerly Integrations)

Two months ago marked the general release of GitHub Apps. Originally, GitHub Apps were named Integrations; as this new functionality is the preferred way to extend GitHub, we've renamed it GitHub Apps. In addition to the already announced deprecation of the Integrations API, we are announcing routing changes that will affect URLs on

Currently, all URLs that reference "integration" or "integrations" redirect so that they instead reference "apps". For example, the link to install an App named Super CI would redirect from to

On November 22nd, URLs that reference "integration" or "integrations" will be removed entirely and this redirection will cease to function, resulting in 404s. Please update your URLs accordingly and if you have any questions, get in touch.

Repository API - read and replace topics for a repository

Today we're introducing additions to the repository topics preview. You can now replace all the topics for a repository.

You can also list the topics for a repository specifically.

In addition to these new endpoints, the topics are also available as part of the payload in the get repository and search repositories endpoints.

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


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

Installations API - updated routes for adding or removing a repository

Today we're releasing a change to the Installations API: updated routes for adding or removing a repository.

The authenticated user must have admin access to the repository. You can authenticate with a personal access token with repo scope or with Basic Authentication.

How can I try it?

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


Give us your feedback

Come talk to us, in the new Platform forum.

Protected Branches API becomes an official part of API v3 on September 1st

The Protected Branches API will be graduating from preview mode on September 1, 2017.

During the preview period you needed to provide the application/vnd.github.loki-preview+json preview media type in the Accept header to opt-in to the changes. Once the preview period ends, you won't have to specify this custom media type.

There will be two breaking changes when the preview gets removed:

We will be removing this endpoint PATCH /repos/:owner/:repo/branches/:branch. The breaking change was announced on 06-27-2016. We will also now be requiring required-pull-request-reviews when calling the \protection endpoint. This breaking change was announced on 12-08-2016.

Please update your environments accordingly and if you have any questions, get in touch.

Specify a commit for a pull request review

Today we're introducing the commit_id input to the create pull request review endpoint. With commit_id, you can specify which commit a review pertains to. This is useful for pull requests with extensive automated reviews that may become invalidated by future pushes.