The cvss field for GitHub security advisories in the REST and GraphQL APIs will be deprecated in favor of the new cvss_severities field. cvss will be removed from the REST API on April 1, 2025, and removed from the GraphQL API on October 1, 2025.
Join the discussion within GitHub Community.
Issue types can now be managed using the REST API, expanding the ability to automate and incorporate them in your workflows. Check out our documentation on issue types for more details. You can also review the examples below to get started.
You can create, update, delete, and list issue types for an organization.
Creating a new issue type:
curl --request POST \
--url https://api.github.com/orgs/{org}/issue-types \
--header 'authorization: token <YOUR-TOKEN>' \
--header 'content-type: application/json' \
--data '{
"name": "Initiative",
"description": "A large body of work that spans a quarter.",
"color": "orange",
"is_enabled": true
}'
You can specify the issue type when creating a new issue, or update it on an existing issue.
Creating a new issue:
curl --request POST \
--url https://api.github.com/repos/{org}/{repo}/issues \
--header 'authorization: ' \
--header 'content-type: application/json' \
--data '{
"title": "Error when refreshing the settings page",
"type": "Bug"
}'
Updating an issue:
curl --request PATCH \
--url https://api.github.com/repos/{org}/{repo}/issues/{issue_number} \
--header 'authorization: ' \
--header 'content-type: application/json' \
--data '{
"type": "bug"
}'
You can search for issues by issue type at the repository or organization level.
Searching within a repository:
curl --request GET \
--url 'https://api.github.com/repos/{org}/{repo}/issues?type=bug' \
--header 'authorization: '
Join the discussion within GitHub Community.
See how to use GitHub for project planning with GitHub Issues, check out what’s on the roadmap, and learn more in the documentation.
Fine-grained Personal Access Tokens (PATs) have been used by millions of users to make tens of billions of API calls over the last two years in public preview. In that time, we’ve added requested features such as management APIs and webhooks, mandatory expiration policies, and usability improvements.
However, feedback has been clear on one item in particular – while fine-grained PATs solve a significant set of challenges in their current state, many organizations cannot fully adopt them due to the lack of support statements and the risk of breaking changes while they’re in public preview. Our goal at GitHub is to ensure that everyone can secure their workflows as best they can, which is why we’re graduating fine-grained PATs to a generally available (GA) state.
This update brings two major changes to PATs at GitHub. Most notably, fine-grained PATs are now enabled by default for all organizations on GitHub, unless that organization or enterprise explicitly disabled them during the preview. The PAT approval flow is also enabled by default, so developers must request organization owner approval in order to successfully use their fine-grained PAT against their organizations.
We’re also updating the release state for both fine-grained PATs and PAT expiration policies. These features are now fully supported by GitHub and adhere to the same breaking change policies as the rest of the product. While there are some scenarios where fine-grained PATs are not yet supported, your organization should be confident in suggesting, or even requiring, the use of these more secure tokens.
Administrators, auditors, and security teams can also look for improved auditability of PATs – the token_id is now included in all API calls and supported as a built-in filter in the audit logs. With this filter, you can now easily track the use of a token throughout your enterprise or organization.
Customers on GHES should expect these changes to arrive in version 3.17.
There are several scenarios where fine-grained PATs are not a suitable solution at this time. GitHub continues to invest in building more secure access patterns and will implement these capabilities over time. You can track our progress and goals on our public roadmap. The most notable scenarios are:
internal repositories in your enterprise, outside of a targeted organizationPackages and Checks APIsWe’re currently focused on implementing enterprise access for GitHub Apps and fine-grained PATs so that enterprise owners can reduce the over-permissioning of their current automation solutions. After that, we’ll continue to invest in this area with a goal of enabling organizations to eventually disable the use of PATs (Classic) for their resources.
To learn more about fine-grained PATs and how your organization can control them, see our documentation on managing your personal access tokens, and enforcing policies for PATs in your enterprise.
Today’s changelog announces API support for issues advanced search, timeline events for issue types, and an update on issue types settings.
You can now use GraphQL and the REST API to perform advanced queries for issues using the AND and OR keywords and nested searches.
For the REST API, you can set the advanced_search parameter to true. Check out the REST API documentation for more details.
http://api.github.com/search/issues?q={query}&advanced_search=true
For GraphQL, you can use the ISSUE_ADVANCED type. Check out the GraphQL documentation for more details.
query {
search(query: "is:issue AND assignee:@me AND (label:support OR comments:>5)", type: ISSUE_ADVANCED, first: 10) {
nodes {
... on Node {
id
}
}
issueCount
}
}
Note that on September 4, 2025, all issue queries will use advanced search by default. This means that after this date:
advanced_search parameter for the REST API.ISSUE GraphQL type will support advanced search.
You can now see events in the issue timeline when issue types are added, updated, and removed from an issue.
Issue types for private repositories only will be retiredWe are retiring the “Private repositories only” setting for issue types. Over the next week, you will no longer be allowed select this setting to specify an issue type for use only in private repositories. All existing issue types with this setting selected that are marked as Private will be removed on March 26, 2025.
In order to continue using these issue types, you will need to unselect the “Private repositories only” setting in the issue types organization settings page before this date. They can then be edited, disabled, or deleted as needed.
Join the discussion within the GitHub Community.
See how to use GitHub for project planning with GitHub Issues, check out what’s on the roadmap, and learn more in the documentation.
Push protection for secret scanning blocks any push that contains a secret. By default, this block can be bypassed, which results in a secret scanning alert in the repository. Delegated bypass controls let you choose who is allowed to bypass push protection, and contributors without permissions to bypass must submit a request for approval by the listed reviewers. These controls can reduce the risk of secrets being accidentally exposed in your codebase.
Managing bypass requests is now available with the REST API, offering flexibility for triaging and reviewing by integrating with your existing workflows.
Reviewers can retrieve bypass requests for an organization or repository with the following endpoints:
GET /orgs/{org}/bypass-requests/secret-scanningGET /repos/{owner}/{repo}/bypass-requests/secret-scanningGET /repos/{owner}/{repo}/bypass-requests/secret-scanning/{bypass_request_number}Reviewers can review a request and dismiss a response to a request with the following endpoints:
PATCH /repos/{owner}/{repo}/bypass-requests/secret-scanning/{bypass_request_number}DELETE /repos/{owner}/{repo}/bypass-responses/secret-scanning/{bypass_response_id}Learn more about how to secure your repositories with secret scanning and push protection.
Beginning February 2025, the beta Copilot /usage endpoints will be deprecated.
No new data will be inserted for retrieval via the beta /usage endpoints. This endpoint will be accessible through February, but the 28 day retention policy will remain.
Enterprise organizations with Copilot licenses not yet migrated from the /usage metrics APIs are impacted by this deprecation.
The deprecation of the beta /usage endpoints is a part of GitHub’s effort to deliver more powerful and flexible data offerings for enterprises, organizations, and teams. The new endpoints provide:
Ensure your organization is no longer consuming the now deprecated /usage endpoints in any jobs, workflows, and analytics tools.
As an alternative to the beta Copilot /usage endpoints, check out the PowerBI template and the Copilot /metrics endpoints.
Join the discussion in the GitHub community.
Today’s changelog brings you a snappier issue creation flow in projects, the ability to convert checklist items to sub-issues, required fields on private repositories, and important updates on tasklist blocks and single issue templates.
Improved issue creation flow in projectsCreating a new issue from a project is now easier than ever. Previously, when you started typing in an issue title in a project, the default was to create a draft issue. However, we’ve heard from user feedback that the primary
desired use case is to create an issue instead of a draft. Now, with this update, you can directly create a new issue by pressing Enter or create a draft with Cmd / Ctrl + Enter.
Required fields on issue forms for private repositoriesYou can now specify required fields on issue forms in private repositories, which ensures that contributors provide essential information before submitting an issue.
Convert checklist items to sub-issuesYou can now convert checklist items in issues directly to sub-issues, making it easier to turn draft or to-do tasks into actionable work items.
Tasklist blocks will be retired and replaced with sub-issuesThe private preview feature, tasklist blocks, will be retired on April 30, 2025. Your feedback from the private preview has been invaluable, helping us shape the release of sub-issues, the replacement for tasklist blocks.
Sub-issues provide a dedicated section within each issue, making it easier to track related work without relying on Markdown. You can manage up to eight levels of hierarchy within a single issue and monitor progress directly in your projects.
We recommend migrating your tasklists to sub-issues before the retirement date.
To migrate, first simply remove the tasklist Markdown syntax to display the list as an issue checklist.
- ```[tasklist]
- - [ ] task 1
- - [ ] https://github.com/github/github/issues/123
- ```
+ - [ ] task 1
+ - [ ] https://github.com/github/github/issues/123
Then, use the Convert to sub-issue feature to convert desired issues or checklist items into sub-issues.
After April 30, 2025, remaining tasklist blocks will no longer be rendered and will instead be converted to raw Markdown. The Tracked and Tracked by fields on projects will no longer be available.
Single issue templates (ISSUE_TEMPLATE.md) will be retiredThe legacy ISSUE_TEMPLATE.md feature will be retired on March 30, 2025. As a replacement, we encourage creating an ISSUE_TEMPLATE/ subdirectory in any of the supported folders to store multiple issue templates. You can then use the template query parameter to specify which template should populate the issue body. For more details, see the documentation.
After March 30, 2025, repositories still using ISSUE_TEMPLATE.md will default to a blank issue form, allowing users to start fresh when creating issues.
On top of the many bug fixes we’ve shipped, we’ve also introduced the following improvements:
Join the discussion within the GitHub Community.
See how to use GitHub for project planning with GitHub Issues, check out what’s on the roadmap, and learn more in the documentation.
As part of the ongoing transition of Enterprise customers and Team plan customers to our new billing platform, the Actions Get workflow usage and Get workflow run usage endpoints will be closing down. The transition of Enterprise and Team plan customers to the new billing platform will complete by April 1, 2025.
Actions usage information is available via the billing platform usage endpoint. This endpoint summarizes Actions usage by SKU, organization, and repository, however it does not provide detailed workflow information. For more information, refer to Getting GitHub Actions billing data from the new response data.
On the new billing platform, workflow information is available in the usage report, which can be requested from the usage page. For more information, refer to Viewing usage.
Learn more about the new billing platform or share feedback on this change in the community discussion.
To support better content moderation, you can now disable comments on individual gists in the UI as well as with the APIs. Once commenting is disabled, existing comments on the gist will be hidden and no new comments can be posted.
To learn more check out the documentation.
Questions or suggestions? Join the conversation in the community discussion.
As a GitHub Enterprise Cloud organization owner, you and your designated users can now use API insights to visualize REST API activity for your entire organization or specific apps and users. This new feature helps you understand the sources of your REST API activity and manage against your primary rate limits—giving you visibility into the timeframe, apps, and API endpoints involved.
The API insights feature is available only at the organization level. By default, only organization owners can access it. However, organization owners can grant access to non-owners by creating a custom role at the organization level, assigning the permission named View organization API insights to the custom role, and then assigning the custom role to an organization member or team. See the documentation for managing organization custom roles.
The API insights feature is available to all GitHub Enterprise Cloud organizations. To access it on your organization home page, select Insights near the top of the page, and then select REST API on the left side of the page.
Use the Period and Interval drop-downs to choose the range of time displayed in the chart and how granularly to display REST API requests on the chart. These drop-downs also set the time range for the “Total REST requests,” the “Primary-rate-limited requests,” and the Actors table below the chart.
The Actors table displays the GitHub Apps and users that made REST API requests in the current organization within the selected time period. Select a GitHub App to display its REST API activity and any primary rate-limiting. Select a user to display their personal REST API activity from personal access tokens (PATs) and OAuth apps acting on their behalf.
We welcome your feedback in the Enterprise community discussions.
Refer to the documentation for API insights for more details about understanding your organization’s REST API activity and investigating primary rate-limiting.
New REST API endpoints for code scanning allow you to request the generation of Copilot Autofix for code scanning alerts. These endpoints also provide the Autofix generation status, along with metadata and AI-generated descriptions for the fixes, and enable you to apply Autofix to a branch. This functionality can be particularly useful for addressing security vulnerabilities programmatically and for tracking the status of alerts with Copilot Autofixes in your system.
To generate Copilot Autofix, call the POST /repos/{owner}/{repo}/code-scanning/alerts/{number}/autofix endpoint.
Additionally, you can retrieve the Autofix and commit it by using the GET /repos/{owner}/{repo}/code-scanning/alerts/{number}/autofix endpoint followed by POST /repos/{owner}/{repo}/code-scanning/alerts/{number}/autofix/commits.
For more information, see: About Copilot Autofix for CodeQL code scanning. If you have feedback for Copilot Autofix for code scanning, please join the discussion here.
Announcement banner fields in GraphQL for enterprises and organizations are being replaced with a new announcementBanner object to simplify their access and better follow our standard styles. The new fields are available today, and the old fields will be removed on April 1, 2025.
The following fields are being removed from the enterprise and organization GraphQL objects:
announcementannouncementCreatedAtannouncementExpiresAtannouncementUserDismissibleThe new GraphQL structure for these fields is:
announcementBanner {
message
createdAt
expiresAt
isUserDismissible
}
Learn more about announcement banners for organizations on GitHub Enterprise Cloud.
Following our “Evolving GitHub Issues” announcement we’ve continued to improve the experience based on your feedback, including closing an issue as a duplicate, a REST API for sub-issues, and expanding the limits for both sub-issues and issue types.
These new features are all available in public preview for you to try. To gain access for your organization, please sign up here.
You can now close an issue as a duplicate of another issue, making it easier to manage your issues and provide more clarity on why they were closed.
When closing an issue, select Close as duplicate from the dropdown to search for and select the duplicate issue. You’ll then see an event in the timeline and note at the top making it clear why it was closed.
You can now use the REST API to view, add, remove, and reprioritize sub-issues, making it easier to automate your use of sub-issues. Check out the documentation to learn more.
You can now have up to 100 sub-issues per parent issue (up from 50), as well as up to 25 issue types in an organization (up from 10), making it easier to manage, classify, and break down work.
You can now view, add, and update issue types on GitHub Mobile.
You can use the has: and no: filters to search for sub-issues and issue types both from a project and the repository issues page, making it easier to find the exact set of issues you’re looking for and make updates.
Example filters include:
– no:type to find all issues that do not yet have a type
– no:parent-issue to find all issues without a parent issue
– has:sub-issue to find all issues that have sub-issues
On top of the many bug fixes we’ve shipped, we’ve also introduced the following improvements:
– If the sub-issue is from a different repository than the parent issue, you will now see the repository name in the sub-issues list.
– In GitHub markdown, pasting in a project link will now show the project name as well as more project details on hover.
– Projects insights charts now use Highcharts, which is an industry standard library for charts, improving our accessibility of projects insights.
– You can now use the UpdateProjectV2Field GraphQL API mutation to directly update all single select field options in one API.
Join the discussion in the community discussion to share your feedback.
See how to use GitHub for project planning with GitHub Issues, check out what’s on the roadmap, and learn more in the documentation.
Based on customer feedback, we have updated how the created_at timestamp works in the Copilot seat details portion of responses from the following REST API endpoints:
/organization/{org}/billing/copilot/seats/enterprises/{enterprise}/billing/copilot/seats/organization/{org}/members/{username}/copilotThe created_at timestamp now shows when a user received Copilot access, rather than when their team, enterprise team, or organization was granted access. This matches the timestamp of the seat’s corresponding seat_added event in the Audit Log.
Currently, you are able to query back up to 90 days worth of events from data tables you have access to when reviewing or utilizing specific events features: Events API (including push events), Atom feed, /timeline, or /dashboard-feed. On January 30th, 2025, we will be modifying the window of data retention for these features from 90 days to 30 days.
We are making this change to help GitHub continue to scale for all our users, while continuing to provide existing customers of these features with the ability to still query and view recent important event information.
The relevant APIs that will be affected are:
– /events : List public events
– /networks/{owner}/{repo}/events : List public events for a network of repositories
– /orgs/{org}/events : List public organization events
– /repos/{owner}/{repo}/events : List repository events
– /users/{username}/events : List events for the authenticated user
– /users/{username}/events/orgs/{org} : List organization events for the authenticated user
– /users/{username}/events/public : List public events for a user
– /users/{username}/received_events : List events received by the authenticated user
– /users/{username}/received_events/public : List public events received by a user
– /feeds : Get feeds
On January 30th, 2025, we will be reducing the window that can be queried across those specified events features from 90 days to 30 days. In advance of that, we will test this change for 24 hours on December 3rd, 2024.
The Dormant Users feature report will also be impacted a result of this change. As of 1/31/25, users who are 31+ days without activity will fall into the dormant category and would appear in the Dormant Users report.
We recommend leveraging a workflow that uses weekly or daily exports if you require further historical access.
If you have concerns, comments, or feedback, please join us in this Discussion in the GitHub Community.
