GitHub has added a REST API endpoint for repository star history that returns historical counts without exposing individual stargazer identities. The endpoint groups stars by calendar week, includes a day-by-day breakdown, and gives maintainers and tool builders a new way to chart repository growth after GitHub restricted identity-level stargazer access.

GitHub is giving star-growth tools a new data source

GitHub has added a new REST API endpoint for something maintainers have wanted for years: a clean history of how a repository’s stars grew over time.

The new endpoint returns historical star counts with timestamps while keeping individual stargazer identities out of the response. GitHub announced it on September 4 as a privacy-safe alternative for tools and integrations that track repository growth.

The route is straightforward:

`GET /repos/{owner}/{repo}/stargazers/history`

Instead of returning a list of people, the API returns aggregate history that can be turned directly into a growth chart.

That changes the problem from “who starred this repository?” to “how did interest in this repository change over time?” — which is usually the question analytics tools actually need to answer.

The response is already shaped for charts

GitHub groups the result by calendar week, with the most recent week first.

Each record contains three useful pieces of data: a `week` timestamp, a `total` count for that week, and a `days` array containing the number of stars created on each day. The daily array starts on Sunday.

A response can look as small as this:

`{ “week”: 1754784000, “total”: 19, “days”: [0, 12, 7, 0, 0, 0, 0] }`

That is enough to build several views without reconstructing history from user-level events. A dashboard can plot weekly totals, calculate daily spikes, compare launch periods, or build a cumulative growth curve.

GitHub also includes zero-count weeks, which helps tools preserve a continuous timeline instead of having to guess whether a missing week means no activity or missing data.

Pagination walks backward through the repository’s history

The endpoint is designed to be read as a time series.

Pages move backward toward the repository’s creation week. Inside each page, weeks are ordered newest to oldest. GitHub says concatenating the pages produces one continuous history.

The default page size is 30 weeks, and callers can request up to 30 records per page. The `page` parameter can go up to 100.

For public repositories, the endpoint can be used without authentication. When fine-grained authentication is used, GitHub requires read access to repository metadata.

That makes the API useful for both public analytics tools and authenticated internal tooling without requiring access to the identities behind the star count.

This follows GitHub’s earlier privacy changes

The new endpoint fills a gap created by GitHub’s privacy-focused API changes earlier this year.

GitHub announced that identity-level stargazer and watcher listings would be restricted to repository administrators and collaborators. The company framed the change around protecting user privacy and responsible use of public data.

That restriction changed the shape of repository analytics. A public tool could no longer assume it should collect a list of individual stargazers simply to reconstruct a star-growth graph.

The new history endpoint provides the aggregate signal directly.

For maintainers, that is a cleaner boundary: repository-growth data stays available, while user identity is no longer a requirement for measuring that growth.

Existing star-history tools can simplify their data model

Many repository analytics tools historically built star history from the stargazer listing endpoint because that endpoint could include the timestamp attached to each star.

That worked, but it meant the tool was processing identity-level records even when the final output was only a chart.

GitHub’s new API removes that extra step.

A tool can fetch weekly counts, keep the `days` breakdown if it needs more detail, and store only the aggregate time series it actually uses. There is no need to maintain a parallel table of user accounts just to produce a growth curve.

GitHub explicitly says the endpoint is intended to help tools and integrations that tracked star growth before the privacy restrictions took effect.

For developers maintaining those projects, the migration path is much closer to the final analytics model they wanted in the first place.

Stars become easier to use as a project signal

GitHub stars are simple, but they are still useful as a rough measure of repository interest.

A total count tells you where a project is today. History tells you how it got there.

That can reveal whether attention arrived gradually or in bursts, whether a release produced a visible jump, or whether a repository has been building interest steadily over months. The new endpoint gives developers that timeline without requiring them to infer it from a public list of people.

It also makes comparisons easier. Tools can normalize weekly growth, look at recent momentum, or show how two repositories moved through similar stages.

The API does not turn stars into a perfect measure of project quality, and it does not need to. Its value is simpler: it makes a familiar GitHub signal much easier to analyze over time.

The endpoint is small, but the design is clean

This is not one of GitHub’s biggest releases of the month.

It is a small API addition with a very clear job.

The endpoint returns the historical signal developers want, keeps the response compact, works for public repositories without authentication, and avoids exposing individual stargazer data.

That combination makes it useful for dashboards, open-source analytics, maintainer tooling, and integrations that want to show repository growth without building an identity dataset around it.

For an API, that kind of narrow design is often exactly what makes it easy to adopt.

The Upgrade Feeling

GitHub’s star-history endpoint is a good example of privacy and developer utility landing in the same design.

Maintainers still get the timeline they care about. Tool builders get data that is already shaped for charts. Public repositories can be queried without authentication. And the API no longer needs to expose who created each star just to show when repository interest grew.

It is a small addition, but a useful one.

Sometimes the best API update is the one that gives developers less data — because the data it keeps is exactly what the product needs.