API enhancements for working with organization permissions
We're introducing several enhancements to allow API developers to take advantage of the improved organization permissions that we are rolling out. Learn about these enhancements and how you can try them out below.
Since we're rolling out the improved organization permissions improvements slowly, these enhancements will only apply to certain organizations at first. Most of these enhancements will degrade gracefully (returning an empty array or something similar) if used on an organization that doesn't support improved organization permissions yet. Check the documentation for your specific API to see if errors are possible.
API enhancements
Team permissions
In our improved permissions system, a team no longer has a single permission that applies to all of its repositories. Instead, each repository is added to a team with its own permission. For example, an organization could use a single team to grant pull access to one repository, push access to a second, and admin access to a third.
The team APIs now support this more granular notion of permissions:
- The Add team repository API accepts a
permission
parameter, so that you can specify whether a team should grantpull
,push
, oradmin
access on a given repository. - In the List team repositories and Check if a team manages a repository API, the response includes a
permissions
attribute, indicating whether the team grantspull
,push
, oradmin
access on each repository. - The
permission
parameter in the Create team and Edit team APIs is deprecated. Since teams can grant a different permission on each repository, this parameter no longer dictates what permission a team grants on all of its repositories. Instead, it dictates the default permission that the Add team repository API will use for requests where nopermission
parameter is specified.
Team privacy
We now allow you to modify the privacy level of your teams. A "secret" team can only be seen by organization owners and people who are members of that team (which is how all teams have worked historically), while a "closed" team is visible to every member of the organization (which makes it easier to use @mentions throughout your organization).
The team APIs now support this new team privacy concept:
- The Create team and Edit team APIs accept a
privacy
parameter, so that you can specify whether a team should besecret
orclosed
. - All team resources in the API now include a
privacy
attribute, indicating whether the team issecret
orclosed
.
Team maintainers
We've added the ability for you to delegate team maintenance to non-owners, reducing the workload for your organization's owners. You can now promote a non-owner member of a team to be a "maintainer" of that team. A maintainer can add and remove team members and change the team's title and description.
The team membership APIs now support this new team maintainer concept:
- The Add team membership API accepts a
role
parameter, so that you can specify whether a given team member should be amaintainer
or a regularmember
. - The List team members API accepts an optional
role
parameter, allowing you to fetch onlymaintainer
s or only regularmember
s. - In the Get team membership and Add team membership APIs, the response includes a
role
attribute, indicating whether a user is amaintainer
or a regularmember
of the team.
Filtering organization members by role
The organization Members list API now accepts a role
parameter, so that you can request to see only the owners (or non-owners) of your organization.
Repository collaborators
We now allow you to add collaborators directly to organization-owned repositories, just like we always have for user-owned repositories.
The collaborator APIs now support organization-owned repositories:
- The Add user as a collaborator API works for organization-owned repositories. We've also added a
permission
parameter to it (currently valid for organization-owned repositories only), so that you can specify what level of access the collaborator should have on the repository. - In the List collaborators API, the response includes a
permissions
attribute describing the permissions that each collaborator has on your organization's repositories.
Preview period
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.
While these enhancements are in their preview period, you'll need to provide the following custom media type in the Accept
header:
application/vnd.github.ironman-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.
Send us your feedback
We would love to hear your thoughts on these enhancements. If you have any questions or feedback, please get in touch with us!