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
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
archivedfield that istrueorfalsedepending on whether the repository was archived. - You can use the REST API to archive repositories by passing the
"archived": trueparameter to the Edit endpoint atPATCH /repos/:owner/:repo.
GraphQL API changes
-
Repository,RepositoryInfo, andRepositoryInvitationRepositoryobjects now contain anisArchivedfield that istrueorfalsedepending on whether the repository was archived.
Webhook changes
-
RepositoryEventwebhooks are now emitted when a repository isarchivedorunarchived.
Search changes
- You can search for archived repositories and their issues and pull requests using the
archived:truesearch 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_installationandintegration_installation_repositoriesevent names will be removed in favor ofinstallationandinstallation_repositories. - The
integration_idkey in webhook payloads and API responses will be removed in favor of theapp_idkey.
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/importGET /repos/:owner/:repo/importPATCH /repos/:owner/:repo/importDELETE /repos/:owner/:repo/importGET /repos/:owner/:repo/import/authorsPATCH /repos/:owner/:repo/import/authors/:author_idGET /repos/:owner/:repo/import/large_filesPATCH /repos/:owner/:repo/import/lfsGET /repos/:owner/:repo/eventsGET /orgs/:org/outside_collaboratorsDELETE /orgs/:org/outside_collaborators/:userPUT /orgs/:org/outside_collaborators/:userGET /feedsPOST /markdownPOST /markdown/rawGET /metaGET /repos/:owner/:repo/issues/:issue_number/timelineGET /users/:username/repos
Additionally, the following endpoints are now available for user-to-server requests:
PUT /repos/:owner/:repo/importPATCH /repos/:owner/:repo/importDELETE /repos/:owner/:repo/importPATCH /repos/:owner/:repo/import/authors/:author_idPATCH /repos/:owner/:repo/import/lfsPOST /repos/:owner/:repo/commits/:sha/commentsPATCH /repos/:owner/:repo/comments/:idDELETE /repos/:owner/:repo/comments/:idPOST /orgs/:org/reposPOST /user/reposGET /repos/:owner/:repo/teamsDELETE /repos/:owner/:repo/issues/comments/:idPATCH /repos/:owner/:repo/issues/comments/:idDELETE /repos/:owner/:repo/issues/:number/assigneesPOST /repos/:owner/:repo/issues/:number/assigneesPUT /repos/:owner/:repo/issues/:number/lockDELETE /repos/:owner/:repo/issues/:number/lockDELETE /repos/:owner/:repo/issues/:id/labelsPUT /repos/:owner/:repo/issues/:id/labelsDELETE /repos/:owner/:repo/issues/:id/labels/(.*?)POST /repos/:owner/:repo/labelsDELETE /repos/:owner/:repo/labels/(.*?)PATCH /repos/:owner/:repo/labels/(.*?)DELETE /orgs/:org/outside_collaborators/:userPUT /orgs/:org/outside_collaborators/:userGET /feedsPOST /repos/:owner/:repo/comments/:id/reactionsPOST /repos/:owner/:repo/issues/:number/reactionsPOST /repos/:owner/:repo/issues/comments/:id/reactionsGET /repos/:owner/:repo/pulls/comments/:id/reactionsPOST /repos/:owner/:repo/pulls/comments/:id/reactionsDELETE /reactions/:idPUT /repositories/:repository_id/collaborators/:usernameDELETE /repositories/:repository_id/collaborators/:usernameDELETE /repos/:owner/:repoPATCH /repos/:owner/:repoPOST /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!
Git Signing APIs are now official
The Git Signing APIs are now part of the official GitHub REST API v3. Signature verification metadata will now be included in commit and tag payloads, and user GPG keys can be created, destroyed, and fetched.
[Updated 11-21-17]
Preview media type no longer required
If you used the Git Signing API during the preview period, you needed to provide this custom media type in the Accept header:
application/vnd.github.cryptographer-preview
As of today, you no longer need to pass this custom media type. Instead, we recommend that you specify v3 as the version in the Accept header:
application/vnd.github.v3+json
[End of updated content]
For more information, see the Git Commit, Git Tag, Repository Commit, and User GPG Keys documentation.
If you have any questions or feedback, please let us know.
Introducing the GraphQL Changelog
GitHub's GraphQL schema changes multiple times a day. We have some neat automation to automatically update our reference documentation whenever the schema is modified, but there wasn't an easy way to visualize the day-to-day additions and modifications to the schema.
We're now happy to announce the GraphQL Changelog. Every day, around 4pm PST, Hubot will automatically compose a post detailing the GraphQL additions made in the last day. We've also got an RSS feed of this changelog if you want to subscribe. To support this workflow, we're using the very awesome graphql-schema_comparator gem, which provides a diff between two schemas.
If you have any questions, feel free to contact us!
Breaking changes to projects API preview and webhook date format
As previously announced on September 1st,
the format of the created_at and updated_at fields in the
projects API preview and project webhook payloads
have been changed to be consistent with the standard YYYY-MM-DDTHH:MM:SSZ ISO
8601 format used by all other APIs and webhooks.
Previously, project webhook payloads would include these fields as an integer number of seconds:
{
"action": "created",
"project_card": {
"created_at": 1503590773,
"updated_at": 1503590773
}
}
And project APIs would include these fields with milliseconds that were always zero:
{
"url": "https://api.github.com/projects/1002604",
"id": 1002604,
"created_at": "2017-08-24T15:56:15.000Z",
"updated_at": "2017-08-24T15:56:15.000Z"
}
Starting today, these fields are returned as YYYY-MM-DDTHH:MM:SSZ formatted
strings in all projects APIs and project, card, and column webhook payloads.
If you have any questions or feedback, please let us know.