Preview the new Team Discussions REST API
Today, we released the REST API that allows you to read and manage team discussions programmatically, and we'll be announcing GraphQL support soon. You can access the REST API during the preview period by providing a custom media type in the Accept header:
application/vnd.github.echo-preview+json
During the preview period, we may change aspects of the API based on developer feedback. If we do, we will not provide any advance notice of the changes, but we will announce them here on the developer blog.
We are really excited to see what integrations you develop around this API! If you have any questions or feedback, please let us know.
New REST API endpoints
- List discussions
- Get a single discussion
- Create a discussion
- Edit a discussion
- Delete a discussion
- List comments
- Get a single comment
- Create a comment
- Edit a comment
- Delete a comment
Updates to the Teams API documentation
We've also updated the location of our Teams REST API documentation. You'll now find the Teams API at the top level in the v3 documentation sidebar (no longer nested under Organizations). The team members, team discussions, and team discussion comments APIs are in the Teams section.
Weak cryptographic standards removal notice
Last year we announced the deprecation of several weak cryptographic standards. Then we provided a status update toward the end of last year outlining some changes we'd made to make the transition easier for clients. We quickly approached the February 1, 2018 cutoff date we mentioned in previous posts and, as a result, pushed back our schedule by one week. On February 8, 2018 we'll start disabling the following:
-
TLSv1/TLSv1.1: This applies to all HTTPS connections, including web, API, and git connections to https://github.com and https://api.github.com. -
diffie-hellman-group1-sha1: This applies to all SSH connections to github.com -
diffie-hellman-group14-sha1: This applies to all SSH connections to github.com
We'll disable the algorithms in two stages:
- February 8, 2018 19:00 UTC (11:00 am PST): Disable deprecated algorithms for one hour
- February 22, 2018 19:00 UTC (11:00 am PST): Permanently disable deprecated algorithms
For more details, head to the Engineering Blog.
Preview the new Organization Invitation API
We're releasing two new endpoints that allow you to programmatically invite new members to an organization using their email or user ID.
New endpoints
Changes to existing endpoints
- We've added two new fields to the existing List pending organization invitations API:
team_countandinvitation_teams_url.
To access these new API endpoints during the preview period, you must provide a custom media type in the Accept header:
application/vnd.github.dazzler-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!
Team Review Requests API becomes an official part of API v3
The Team Review Requests API just graduated from preview mode. It's now an official part of the GitHub REST API v3.
As outlined in this blog post we will be making a breaking change to the API. Going forward, when you GET /repos/:owner/:repo/pulls/:number/requested_reviewers it will return both users and teams in a hash syntax, instead of only users. Please take the time to update your API's accordingly.
Preview media type no longer needed
If you used the Team Review Requests API during the preview period, you needed to provide a custom media type in the Accept header:
application/vnd.github.thor-preview+json
Now that the preview period has ended, 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
Please note, that GitHub Enterprise versions that do not yet support the Team Review Requests API will still require the custom media type.
Onward! Thanks again to everyone that tried out the Team Review Requests API during the preview period.
Issue Events API - Dismissed Review Event State
As previously announced, today we introduced a breaking change to the dismissed_review object in the Issue Events API and Issue Timeline API.
Going forward, the state will be a more informative string instead of an integer. Possible strings include commented, approved, or changes_requested. The API will no longer include the dismissal_commit_id field if a commit was not involved in the dismissal.
Please update your code accordingly, and let us know if you have any questions.
Preview adding a Lock Reason via the Lock Issue API
When locking an issue via the issues API, you can now provide an optional reason that will be visible to anyone who views the issue. Valid lock reasons are "off-topic", "too heated", "resolved", and "spam". Providing a lock reason can help make it clearer to contributors why an issue was locked, and what kinds of behavior may result in issues being locked in the future. This change will be available on both the REST API as well as the GraphQL API.
To set a lock_reason during the preview period, you must provide a custom media type in the Accept header:
application/vnd.github.sailor-v-preview+json
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.
To our GitHub Enterprise customers: issue lock reasons will be available in the next Enterprise release (2.13), but not in the current version or older versions.
REST API changes
-
Issue and pull request responses now contain an
active_lock_reasonfield that shows thelock_reasonthat was selected for an issue or pull request, if it is currently locked and a reason was provided. - You can use the REST API to pass an optional
lock_reasonparameter to the Lock issue atPUT /repos/:owner/:repo/issues/:number/lock. -
Issue and pull request event responses now contain a
lock_reasonfield that shows thelock_reasonthat was selected for alockedevent.
GraphQL API changes
-
Lockableobjects now contain anactiveLockReasonfield that shows thelock_reasonthat was selected for an issue or pull request, if it is currently locked and a reason was provided. - You can now lock issues and pull requests through the GraphQL API through the
lockLockablemutation, which includes an optionallockReasonparameter.
If you have any questions or feedback, please let us know!
Issue Events API - Dismissed Review Event State
On January 17, 2018, we will introduce a breaking change to the dismissed_review event in the Issue Events API.
Currently, the REST API v3 passes an integer for state, but with this change it will pass a more informative string. Possible strings include commented, approved, or changes_requested. Along with this breaking change, the API will no longer include the dismissal_commit_id field if a commit was not involved in the dismissal.
Please update your code accordingly, and let us know if you have any questions or feedback!
Preview GraphQL API v4 Node IDs in REST API v3 resources
To help with migrating from our REST API v3 to GraphQL API v4, we're introducing a new preview period to include the GraphQL node ID in the response for the following REST API v3 resources:
- Deployments
- Gists
- Git Blobs
- Git Commits
- Git References
- Git Tags
- Issues
- Labels
- Milestones
- Organizations
- Projects
- Pull Requests
- Reactions
- Releases
- Repositories
- Statuses
- Teams
- Users
To access the API during the preview period, you must provide a custom media type in the Accept header:
application/vnd.github.jean-grey-preview+json
Example response from Users which includes node_id:
{
"id": 79995,
"login": "dewski",
"node_id": "MDQ6VXNlcjc5OTk1"
}
Fetching the same user using the node interface in our GraphQL API v4:
{
node(id: "MDQ6VXNlcjc5OTk1") {
... on User {
databaseId
login
id
}
}
}
Which would return:
{
"data": {
"node": {
"databaseId": 79995,
"login": "dewski",
"id": "MDQ6VXNlcjc5OTk1"
}
}
}
For more information, see "GraphQL Global Relay IDs."
Please note that node_id is only available to GitHub Enterprise customers on 2.12 (and future GHE versions when they are released).
If you have any questions or feedback, please let us know on the GitHub Platform Forum.
Introducing new ways to build with GitHub Enterprise 2.12
Yesterday, we released GitHub Enterprise 2.12. This release includes a few updates relevant to the platform community including GitHub Apps, global webhooks, GitHub Enterprise version information in API responses, and new and improved documentation.
GitHub Apps compatibility
GitHub Apps is now enabled in early access for GitHub Enterprise 2.12. This means GitHub Apps can be created and installed on the GitHub Enterprise instance. We’re still customizing the GitHub Apps experience for the unique needs of an on-premise environment—hence the “early access”—and we’d appreciate your feedback along the way.
Global webhooks
In addition to Organization and Repository-specific webhooks, teams can now configure webhooks that are global to the entire instance of GitHub Enterprise. Global webhooks give administrators the ability to configure notifications for account creation and deletion, as well as membership changes. These events are also available to integrators, adding depth to any administrative features your integration offers. Check out help or the API documentation for more details.
Adding GitHub Enterprise version info to API responses
GitHub Enterprise 2.12 also returns the GitHub Enterprise version via the Meta API and response headers for all REST API endpoints.
Check out updated documentation
As part of the GitHub Apps release, you'll find refreshed documentation:
- A new guide for getting started with building apps.
- An updated guide that outlines the differences between GitHub Apps and OAuth Apps.
- A streamlined top navigation that makes Enterprise documentation accessible from any page.
We can’t wait to see what you’ll build with these new features. Learn more on the release blog.
If you have any questions about GitHub Apps, or want to collaborate with other integrators, check out the Platform Forum.
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.