api

Subscribe to all “api” posts via RSS or follow GitHub Changelog on Twitter to stay updated on everything we ship.

→ ~ cd github-changelog
→ ~/github-changelog|main git log main
showing all changes successfully

REST API insights for organizations is now generally available

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.

Who can access it

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.

Where to find it

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.

An image of an organization homepage where selecting Insights and then REST API will navigate to the new API insights feature.

How to use it

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.

An image of the API insights feature page showing the Period drop-down expanded for selecting the time period of REST API activity to include.

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.

An image of the API insights feature page showing a table of actors, including GitHub Apps and users, that created REST API activity in the selected time period.

Tell us what you think

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.

See more

Copilot Autofix can now be generated with the REST API (Public Preview)

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.

See more

Replacement of announcement banner GraphQL fields

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:

  • announcement
  • announcementCreatedAt
  • announcementExpiresAt
  • announcementUserDismissible

The new GraphQL structure for these fields is:

announcementBanner {
  message
  createdAt
  expiresAt
  isUserDismissible
}

Learn more about announcement banners for organizations on GitHub Enterprise Cloud.

See more

GitHub Issues & Projects – Close issue as a duplicate, REST API for sub-issues, and more!

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.

🧹 Close an issue as a duplicate

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.

⚙ REST API support for sub-issues

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.

➕ Increased limits for sub-issues and issue types

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.

Issue type organization settings showing maximum limit of 25 issue types

📱 Issue types on GitHub Mobile

You can now view, add, and update issue types on GitHub Mobile.

Issue types on GitHub Mobile

🔍 Improved filtering for sub-issues and issue types

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.

Issue filtering using has filter

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

✨ Additional improvements

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.

✍ Tell us what you think!

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.

See more

Update to seat `created_at` timestamp in the Copilot user management REST API [Public Preview]

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}/copilot

The 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.

See more

Upcoming changes to data retention for Events API, Atom feed, /timeline and /dashboard-feed features

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.

Why are we making changes?

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.

Which APIs will be impacted in this change?

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

When can you expect the changes to occur?

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.

Additional support

As part of this change, we are adding an additional event (DiscussionEvent) as a new EventType for the Events API. This will allow you to query for an event related to Discussions that was not previously available.

We recommend leveraging a workflow that uses weekly or daily exports if you require further historical access.

Where can I learn more?

If you have concerns, comments, or feedback, please join us in this Discussion in the GitHub Community.

See more

View an organization’s REST API activity with API insights in public preview

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, currently in public preview, 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.

Who can access it

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.

Where to find it

The API insights public preview feature is enabled for 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.

An image of an organization homepage where selecting Insights and then REST API will navigate to the new API insights feature.

How to use it

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.

An image of the API insights feature page showing the Period drop-down expanded for selecting the time period of REST API activity to include.

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.

An image of the API insights feature page showing a table of actors, including GitHub Apps and users, that created REST API activity in the selected time period.

Tell us what you think

We welcome your feedback in this community discussion.

Refer to the documentation for API insights for more details about understanding your organization’s REST API activity and investigating primary-rate-limiting.

See more

New PAT rotation policies preview and optional expiration for fine-grained PATs

Enterprise and organization administrators can now set limits on token lifetimes for the personal access tokens (PATs) used against their resources. These policies mandate token rotation on a regular basis and reduce how long a compromised token is good for, while also providing a lever to reduce the use of less-secure PATs in your company. This public preview is available for all enterprises and organizations, and will be included in GHES 3.16.

Administrators can choose a maximum lifetime between 1 and 366 days for fine-grained PATs and PATs (Classic).
The policies for each token type are distinct, so you can promote the use of fine-grained tokens with a longer lifetime while driving down PAT (Classic) usage with a very short lifetime requirement.

Screenshot of the policy UI for fine-grained PATs, showing that fine-grained PATs must expire within 90 days and that enterprise administrators are exempt

The policies apply when tokens are created, regenerated, or used.

If you want to create a PAT for a specific organization, but that organization or enterprise has a lifetime policy, your lifetime options will be restricted. Additionally, if you try to use an already-created PAT in an organization or enterprise with a policy, the call will fail if the token has too long a lifetime.

If your enterprise has audit log streaming enabled, you’ll be able to track when this policy has blocked a PAT from being used.

Allowing infinite-lifetime fine-grained PATs

With this change, developers can now create fine-grained tokens with no expiration for personal projects, an option that developer feedback said was needed to migrate from PATs (Classic) to more secure fine-grained PATs.

Enterprises and organizations have a 366 day expiration policy for fine-grained tokens by default, so developers still can’t create infinite lifetime fine-grained PATs for use against an organization they’re a member of, unless the administrator relaxes the policy.

For more information, see our documentation on Enterprise and Organization PAT policies.

Join the discussion within GitHub Community for feedback and questions.

See more

Client IDs are now included in App API responses

The client_id field is now included in all API responses that describe a GitHub App. We are shifting to use the client ID as the primary identifier for an app, as client IDs are globally unique while application IDs and names are not.

Historically GitHub has used the app_name (aka slug) or the app_id (a database ID) to identify applications in our APIs. However, the app name is not immutable and the app ID is not sufficiently globally unique. We are gradually moving all App-related APIs to support the use of the client_id of an application as their primary identifier instead of the name or database ID – this was first seen in our change to support using the client ID to mint JWTs used for installation tokens.

We are making this change to prepare for upcoming features that allow programmatic management of applications in your enterprise. This additional data will make it easier to find the client ID of an application that you are interested in.

For more information about how to get application information, see our REST API documentation.

See more

Retrieve the code security configuration currently applied to a repository via API

You can now retrieve the code security configuration applied to a specific repository via the repos endpoint in the REST API. Previously, you could only retrieve all the repositories associated with a configuration rather than the inverse.

Code security configurations help you manage and enforce the enablement of your security features like Dependabot, code scanning, and secret scanning.

To learn more about retrieving code security configurations with our repository REST API endpoint, check out our docs here.

See more

Secret scanning push protection is supported for content upload REST API endpoints

Push protection blocks you from pushing secrets to a repository and generates an alert whenever you bypass the block.

Push protection is now supported for the following REST API endpoints:
* Create a blob
* Create or update file contents

If the content of a PUT request to these endpoints includes a secret, the API will respond with a 409 error and provide a link for bypassing push protection, along with a placeholder_id.

There is also a new API endpoint to bypass push protection programatically, Create a push protection bypass. You or your application can use the placeholder_id from your push protection block in your call to this endpoint.

You need to be the individual or application that initially got blocked to be able to bypass the block successfully.

See more

GitHub Issues & Projects – GraphQL and webhook support for project status updates and more!

Today’s changelog brings you GraphQL and webhook support for project status updates and project custom field changes directly in the webhook event!

⚙ Using GraphQL and webooks with project status updates

Following our release earlier this year for project status updates, you can now interact with project status updates using GraphQL and webhooks. This unlocks new ways to automate how you provide and gather project status update information.

GraphQL

There is a new ProjectV2StatusUpdate GraphQL object to interact with project status updates, so you can view, create, update, and delete status updates.

Below is an example query to create a new project status update.

mutation {
  createProjectV2StatusUpdate(
    input: {projectId: "0123456", body: "We wrapped up our bug bash following the beta rollout. We're back on track for our GA date in August! 🚀", startDate: "2024-06-03", targetDate: "2024-08-09", status: ON_TRACK}
  ) {
    statusUpdate {
      id
      startDate
      targetDate
      body
      bodyHTML
      status
    }
  }
}

Webhooks

Project status updates are included in the new projects_v2_status_update webhook event, so you can understand and be notified when a new project status update is provided.

You must be subscribed to this event from the organization settings page to receive this information.
organization settings for webhook event

Below is an example of a webhook event.

{
    "action": "edited",
    "projects_v2_status_update": {
        "id": 32633,
        "node_id": "PVTSU_lADOBH2n9s4Ajp6VzX95",
        "project_node_id": "PVT_kwDOBH2n9s4Ajp6V",
        "creator": {
          ...
        },
        "body": "We've kicked off this project and are feeling confident in our rollout plan. More updates and demos to come next week!",
        "start_date": "2024-06-24",
        "target_date": "2024-08-16",
        "status": "ON_TRACK",
        "created_at": "2024-06-24T20:27:48Z",
        "updated_at": "2024-06-24T20:30:47Z"
    },
    "changes": {
        "body": {
            "from": "We're still planning this out and are kicking off soon.",
            "to": "We've kicked off this project and are feeling confident in our rollout plan. More updates and demos to come next week!"
        },
        "status": {
            "from": "INACTIVE",
            "to": "ON_TRACK"
        },
        "start_date": {
            "from": null,
            "to": "2024-06-24"
        },
        "target_date": {
            "from": null,
            "to": "2024-08-16"
        }
    },
    "organization": {
        ...
    },
    "sender": {
        ...
    }
}

➕ Using webhooks for project custom field changes

Project custom field changes are now included directly in the project_v2_item webhook event when a project item’s fields are edited, removing the need to send an additional GraphQL query. This gives you the previous and current field values to understand how project fields change over time and how long they have a particular value, allowing you to understand how long an item was In progress before moving to Done status.

Below is an example of the webhook which includes the previous and current value for single select, text, number, iteration, and date project custom fields using the changes parameter.

"changes": {
    "field_value": {
        "field_node_id": "PVTSSF_lADOBH2n9s4Aje1Izgb1kEs",
        "field_type": "single_select",
        "field_name": "Status",
        "project_number": 18,
        "from": {
            "id": "f75ad846",
            "name": "Todo",
            "color": "GREEN",
            "description": "This item hasn't been started"
        },
        "to": {
            "id": "47fc9ee4",
            "name": "In Progress",
            "color": "YELLOW",
            "description": "This is actively being worked on"
        }
    }
},

✨ Bug fixes and improvements

  • Added the convertProjectV2DraftIssueItemToIssue GraphQL mutation to convert drafts to issues
  • Fixed an error message when resizing columns in the table layout
  • Fixed errors when migrating a classic project to the new Projects experience
  • Fixed a bug where updating an issue in the project side panel didn’t reflect in the project view
  • Fixed the rendering of special characters in a single-select field description from the table layout cell dropdown
  • Fixed a bug where a space could not be added in project chart titles

✍️ Tell us what you think!

Join the conversation 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.

See more

GitHub Apps can now use the client ID to fetch installation tokens

Developers of GitHub Apps can simplify their application by using the client ID for both OAuth flows and the installation token flow.

To date, GitHub Apps have had two different IDs to manage – the application ID and the client ID. The application ID was only used to mint a JWT, subsequently used to fetch an installation token. The client ID is used with the OAuth flow to sign in users and request installations. These two values equally identify the application and the question of which one to use where caused unnecessary developer friction. You can now use the client ID in the place of the application ID when minting JWTs.

The application ID is not being deprecated at this time, nor are their plans to remove it. However, compatibility with future features will rely on use of the client ID, so updating is recommended.

The specific change allowed here is that when minting the JWT that proves your app is in posession of an application’s private key, you can use the client ID for the iss claim. Note that application IDs are ints, while client IDs are strings, if using a typed language.

require 'openssl'
require 'jwt'  # https://rubygems.org/gems/jwt

# Private key contents
private_pem = File.read("YOUR_PATH_TO_PEM")
private_key = OpenSSL::PKey::RSA.new(private_pem)

# Generate the JWT
 payload = {
 # issued at time, 60 seconds in the past to allow for clock drift
  iat: Time.now.to_i - 60,
  # JWT expiration time (10 minute maximum)
  exp: Time.now.to_i + (10 * 60),
--- # GitHub App's App ID
--- iss: "12345"
+++ # GitHub App's Client ID
+++ iss: "Iv23f8doAlphaNumer1c"
}

jwt = JWT.encode(payload, private_key, "RS256")
puts jwt

Note that Octokit still expects the use of the App ID in its setup – the Octokit SDK will be updated in the future to support use of the client ID.

You can find the client ID for your application in its settings page:

A screenshot of an app's settings, showing both the client ID and the application ID

Client IDs and application IDs are not secrets, and are expected to be visible to the end user – you do not need to change how you handle your IDs when making this update.

For more information about minting JWTs to get an installation token, see ‘Generating a JWT for a GitHub App’.

See more

New limits on scoped token creation for GitHub Apps

As a proactive measure to protect Github.com availability, GitHub Apps that attempt to create high-complexity scoped installation tokens will receive failures if they would individually reference too many repositories. At the time of release, no GitHub App is above these limits – the limit is approximately 8 times higher than what any app is consuming. See below for details on how complexity is calculated.

Scoped tokens allow a GitHub App to create an installation token that has just a subset of the privileges that the app has within an organization – both a reduced set of repositories, as well as permissions.
In this way, an application with many permissions and access to many repositories can still safely request a token that’s good for just the access that’s currently required, a useful least-privilege feature.

When requesting a scoped token, applications can indicate both the permissions and repositories that are desired. Both parameters are optional, and if either is omitted the full corresponding access will be given to the token, either all granted permissions or all accessible repositories.

The first limit being added is when the repositories are included in the token request – now, no more than 500 individual repositories can be listed.

The second limit is if the repositories are not listed but permissions are, and the application is installed on some repositories in the organization – as in, it has not been explicitly granted access to all repositories in the organization.
In that case, the limit is based on the number of permissions being requested and the number of repositories the application has access to. If the complexity limit is exceeded, the application will recieve an error: Too many repositories for installation, and provides the maximum number of repositories the application can have access to in order to succeed, as well as other options to reduce the complexity of your token, which are provided here as well.

To reduce the complexity of your token request, you can do one of the following:
1. Reduce the number of repositories that the application has access to in the organization.
2. Reduce the number of permissions requested for the token.
3. Set the application to have access to “all” of the organization’s repositories.
4. Not request a scoped token at all, and instead request a standard installation token.

Any of these options will reduce the complexity of the token and allow the application to fetch tokens for that organization once again.

To learn more about GitHub App scoped token issuance and installation, see our documentation:

  • “Generating an installation access token for a GitHub App”
  • “Reviewing and modifying installed GitHub Apps”
  • REST API: “Create an installation access token for an app”
    • See more
    View more changes