GitHub Closed the List, Then Returned the Trend

A live request to GitHub’s new star-history endpoint returned this:

{"week":1788048000,"total":105,"days":[13,15,18,21,24,14,0]}

That little object knows a repository gained 105 stars during one week and how those stars were distributed across seven days. It does not know who clicked the button.[4][5]

GitHub [announced the endpoint on September 4][3] as a “privacy-safe alternative” to the identity-bearing stargazer lists it restricted earlier this year. The route is GET /repos/{owner}/{repo}/stargazers/history. Its pages move backward through a repository’s life, returning a weekly total and a seven-number daily breakdown. Weeks with no stars remain in the series. The documentation warns that its day and week boundaries do not necessarily align with UTC.[4]

I like the shape of it. Most star-history charts never needed a directory of people. They needed a line going up, flattening out, or jumping after a release. Returning that line directly is more useful than handing every analytics tool a pile of identities and expecting each one to discard them responsibly.

The replacement came after the break

On June 30, GitHub said it would limit the public stargazer and watcher list endpoints to repository administrators and collaborators. GitHub attributed the change to large-scale collection of those lists for spam, and warned that other callers could begin receiving empty responses or HTTP 403.[1] That is a credible reason to stop serving the data. A star may be a public action, but making millions of public actions cheap to enumerate gives spammers a much sharper instrument than an ordinary repository page does.

The restriction also broke tools that had used timestamped stargazer records to calculate growth. GitHub acknowledged that disruption in an [August 28 community announcement][2], then offered the aggregate endpoint as a direct response. Its new route supplies the common analytical result without the raw identity feed.

This is the part I find frustrating. One broad endpoint was serving two different jobs: showing who starred a project and measuring how interest changed over time. GitHub closed the risky path first and separated those jobs afterward. Maintainers and tool authors absorbed the gap.

GitHub has a solid defense for moving first. It said the collection was already happening at scale. Waiting for a polished migration path would have prolonged the abuse, and platform operators do not owe spammers a deprecation window. Protecting users can justify a breaking change when the abused data is the feature rather than an incidental implementation detail.

The urgency does not excuse the sequence. GitHub could have launched the aggregate route alongside the restriction, perhaps with a brief overlap for legitimate tools. If even that was unsafe, the announcement could have said so plainly. Once GitHub understood that maintainers needed the trend rather than the identities, the safer answer belonged in the intervention itself.

Seven numbers instead of names

I will not treat “privacy-safe” as an audit result. The live response confirms that this endpoint omits identities; it does not prove that every aggregate is harmless in every context. A sharp one-day spike can reveal when attention arrived, and activity around a tiny project may be easy to correlate with other public events. Aggregation reduces what the API exposes without making inference impossible.

That reduction matters. The endpoint answers a narrower question with less data. It is a better default than exposing a reusable identity list because one popular chart happens to need timestamps.

Platforms collect plenty of public actions that become more invasive when they are packaged for bulk retrieval. The useful design move is to start with the purpose. If maintainers need a trend, return the trend. A feature that truly requires identities can have a separate access policy and an explanation for why it needs them.

The JSON object at the top is almost comically plain. Seven numbers and a total replaced a feed of people. GitHub should have shipped it sooner. I would still rather build a chart from that object than ask a charting tool to forget names it never needed.

Sources

[1] https://github.blog/changelog/2026-06-30-upcoming-access-restrictions-to-public-api-endpoints-and-ui-views/ — Upcoming access restrictions to public API endpoints and UI views [2] https://github.com/orgs/community/discussions/206104 — Update: new API endpoint available for privacy-safe star history data [3] https://github.blog/changelog/2026-09-04-new-api-endpoint-provides-privacy-safe-star-history-data/ — New API endpoint provides privacy-safe star history data [4] https://docs.github.com/rest/activity/starring?apiVersion=2026-03-10#get-repository-star-history — REST API endpoints for starring [5] https://api.github.com/repos/cli/cli/stargazers/history?per_page=1 — Live star-history response for cli/cli