Deprecating the beta media type

Now that the GitHub API is serving the v3 media type by default, we are deprecating the legacy beta media type.

We will eventually remove support for the beta media type, but we have no official retirement date to announce at the moment. When the time comes, rest assured that we'll announce the retirement with plenty of notice. In the meantime, existing API clients that rely on the beta media type should start making plans to migrate to v3. The beta media type differs from v3 in just a few places. In most cases, migrating an application from the beta media type to the v3 media type is smooth and painless.

As always, if you have any questions, please get in touch.

Extending the preview period for the Deployments API

The preview period for the new Deployments API continues to yield valuable feedback from developers. In early March, we used that feedback to improve the payload format that integrations can use to customize deployments. A few weeks later, we began integrating with the new Combined Status API to help ensure that only verified code gets deployed, even if you have multiple systems verifying different aspects of your software.

To give developers time to explore these recent refinements to the Deployments API, we're extending the preview period for a little while longer. As always, if you have any questions or feedback, please get in touch.

Reminder: Default media type will change on April 15

Just a friendly reminder: On April 15, 2014, the GitHub API will start serving the v3 media type by default. Please see the original announcement for full details about this change, who it affects, and how to ensure that you are prepared.

If you have any questions, please get in touch.

Recommendation: Reset OAuth authorizations

As announced earlier today, we are actively responding to the recently-disclosed Heartbleed security vulnerability in OpenSSL. While at this time GitHub has no indication that the attack has been used beyond testing the vulnerability, we recommend that integrators reset the API authorizations for their OAuth applications.

We've added a new API method for this exact purpose. Calling this method will invalidate the old token and return a new token for applications to store and use in its place. This new method provides a safe way to reset user authorizations without requiring users to re-authorize the application on the web.

Integrators can also use the existing revocation methods to revoke all tokens or revoke a single token for their applications.

If you have any questions or feedback, please get in touch.

Understanding search results and potential timeouts

Some queries are computationally expensive for our search infrastructure to execute. To keep the Search API fast for everyone, we limit how long any individual query can run. In rare situations when a query exceeds the time limit, the API returns all matches that were found prior to the timeout.

Starting today, the Search API also now informs you when such a timeout happens. Reaching a timeout does not necessarily mean that search results are incomplete. It just means that the query was discontinued before it searched through all possible data. More results might have been found, but also might not.

In some cases, if you know that your search results are potentially incomplete, you might think about the data differently. By exposing timeouts when they happen, the API helps you better understand how to interpret the results.

We hope this is useful as you integrate with the Search API. In the meantime, we're working on improving search so that these timeouts occur as rarely as possible. If you have any questions, let us know.

Grant access to create public repositories without granting access to private repositories

The Create Repository method now allows creating public repositories via OAuth with public_repo scope. This means you can safely grant third party applications the ability to create public repositories on your behalf without granting access to your private repositories.

If you have any questions or feedback, please get in touch.

Preview the New Combined Status API

What does it mean for a branch to be "green?" The Status API helps thousands of teams answer that question. Developers use it to record the status of continuous integration builds, contributor license agreements, code coverage analysis, automated security testing, dependency management, and more.

For many teams, a branch is considered "green" only when all of their various status checks are successful. With the new Combined Status API, developers can easily fetch this single, consolidated status for any branch, commit, or tag.

Status context

To help multiple service providers use the Status API simultaneously, statuses now support a context field. This field allows a provider to distinguish its statuses from another provider's statuses. For example, your Jenkins builds might use a context of ci/jenkins, while your Brakeman checks might adopt a context of security/brakeman.

The new Combined Status endpoint returns a single, combined state, as well as the latest status from each context. Systems that consume status updates can now get all the information they need in one place.

Opt-in

The existing Status API continues to work as it always has. The context field is entirely optional, and the color of the merge button on pull requests does not currently take context into account.

Preview period

We're making this new API available today for developers to preview. During this period, we may change aspects of the Combined Status API from time to time. We will announce any changes here (on the developer blog), but we will not provide any advance notice.

We expect the preview period to last 30-60 days. At the end of preview period, the Combined Status API will become an official component of GitHub API v3. At that point, this new API will be stable and suitable for production use.

We hope you'll try it out and send us your feedback!

Pagination changes for some resource lists

In an effort to keep the API fast for everyone, we're enabling pagination on some API methods that previously did not support it. Beginning today, the methods below will paginate if you include page or per_page query parameters. Starting April 17th, 2014, these methods will always return paginated results. If you have any questions or run into trouble, feel free to get in touch.

Here's the complete list of updated methods:

Gist comments

GET /gists/:gist_id/comments

Gist commits

GET /gists/:gist_id/commits

Gist forks

GET /gists/:gist_id/forks

Git refs

GET /repos/:owner/:repo/git/refs

Issue labels

GET /repos/:owner/:repo/issues/:number/labels

Milestone labels

GET /repos/:owner/:repo/milestones/:id/labels

Organization teams

GET /orgs/:org/teams

Pull Request commits

GET /repos/:owner/:repo/pulls/:number/commits

Pull Request files

GET /repos/:owner/:repo/pulls/:number/files

Release assets

GET /repos/:owner/:repo/releases/:id/assets

Repository collaborators

GET /repos/:owner/:repo/collaborators

Repository contributors

GET /repos/:owner/:repo/contributors

Repository branches

GET /repos/:owner/:repo/branches

Repository downloads

GET /repos/:owner/:repo/downloads

Repository keys

GET /repos/:owner/:repo/keys

Repository labels

GET /repos/:owner/:repo/labels

Repository tags

GET /repos/:owner/:repo/tags

Repository teams

GET /repos/:owner/:repo/teams

Team members

GET /teams/:id/members

Team repositories

GET /teams/:id/repos

User emails (v3 media type only)

GET /user/emails

User keys

GET /users/:user/keys
GET /user/keys

Page Build Event for Webhooks

We've made it even easier to track the status of your GitHub Pages builds. By subscribing to the new page_build event, your application will receive an event payload containing the results of each build. (As always, these builds occur automatically following each push to a GitHub Pages-enabled branch.)

If you have a webhook with the "send me everything" option selected (or if you use the "wildcard event" via the API), you will receive the page_build event after the next build of your GitHub Pages site. Alternatively, if you prefer to subscribe to specific event types, you can add to the new page_build event to your webhooks via your repository's webhook settings page or via the webhooks API.

For more information, be sure to check out our guide on working with webhooks. If you have any questions or feedback, please drop us a line.

Reminder: March 12 Cutover Test for Default Media Type

In January, we announced an upcoming change to the default media type. To help developers assess the impact of that change before it becomes permanent, we're performing a 24-hour cutover test next week.

From approximately 12:01am UTC to 11:59pm UTC on March 12, the API will respond with the v3 media type by default. (See the start time for the cutover test in your time zone.)

Follow @GitHubAPI to receive updates before and after the test.

Please see the original announcement for full details. If you have any questions, please get in touch.