GitHub Ships a Star History API: the Growth Charts That Broke Earlier This Year Have an Official Fix

If you maintain an open-source project you have seen the star growth curve. A lot of those charts broke earlier this year, because GitHub restricted the “list who starred this repo” endpoints to admins and collaborators.

On 2026-09-04, GitHub’s changelog announced the replacement: a new star history REST API endpoint that returns timestamped historical star counts without exposing any individual stargazer. Verified 2026-09-07.

1. What was taken away first

The announcement states the background directly: “Earlier this year, stargazer listing endpoints were restricted to admins and collaborators to protect user privacy.”

That change barely touched day-to-day development, but it broke an entire class of tooling: star growth charts, open-source trend leaderboards, and the dashboards investors use to watch project momentum. Almost all of them worked the same way — pull the full stargazer list along with each star’s timestamp, then compute the curve locally. Lock the list, lose the curve.

2. What the new endpoint gives back

Per the announcement, you can now:

1. Retrieve historical star counts with timestamps without exposing individual stargazer data.
2. Update tools and integrations that previously tracked star growth before the privacy restrictions took effect.

The design principle is clear: you wanted the curve, not the roster. Producing the curve used to require over-collecting identity data. Now the aggregate time series is served directly.

GitHub points to the REST API docs for parameters and opened a Community discussion for feedback.

3. Who needs to change something

• Maintainers running their own star charts. If your script still calls the old stargazer endpoints and now gets a permission error as a non-admin, switching to the new endpoint fixes it.
• Anyone running an open-source dashboard or leaderboard. This is the only supported way to restore the feature. Scraping around it breaks the terms and breaks in practice.
• Teams using star counts as an evaluation signal. The new endpoint is aggregate: you get the trend, not the who. If your analysis relied on stargazer identity — spotting bot-inflated stars, say — that method no longer has an official API path.

4. The pattern worth noticing

This fits a consistent direction across GitHub’s recent releases: separate aggregate information from personal identity.

The same period brought a run of blocking-related improvements — blocking users from discussion comments in personal repositories, blocking directly from security advisories, closing contributions authored by a blocked user. The through-line is the same: the platform will still hand you data, but is no longer willing to let anyone easily assemble a full picture of what a given account has done.

For tool builders that implies a design shift: new capabilities will increasingly ship as aggregate APIs rather than raw listing APIs. Assume you cannot get the roster when you design the pipeline.

5. Practical takeaway

If you track project growth for a portfolio, a report, or an adoption decision:

• Star curves work again without third-party caches or scraping.
• Don’t let star count be the only signal. Stars respond to short-term promotion. Read commit cadence, open issue count and last push date alongside them — all publicly available through the API.

The same week also brought three GitHub Actions updates and CodeQL 2.26.4; we covered the Actions changes in GitHub Actions: three updates in early September.

Source: GitHub’s official changelog entry, New API endpoint provides privacy-safe star history data (2026-09-04), read directly. Verified 2026-09-07. Consult the GitHub REST API documentation for exact parameters and rate limits. Plan pricing is summarised on our GitHub Copilot tool page.