GitHub's star history endpoint restores star-chart data after stargazers cut

GitHub's answer to the stargazers restriction

Earlier this year GitHub stopped letting just anyone page through a repository's stargazers list. According to a dev.to post by Yusuf Cengiz, the listing was restricted to a repository's admins and collaborators, which cut off the star history tools that had been using it as their data source.

In September, Cengiz writes, GitHub shipped a purpose-built replacement: a star history endpoint at GET /repos/{owner}/{repo}/stargazers/history. It exposes the same underlying signal those tools wanted — how a repository accumulated stars over time — but as pre-aggregated weekly buckets instead of a list of individual stargazers.

What the endpoint returns

The response is an array of week objects, newest first. Each entry carries a Unix timestamp identifying the week, a total for that week, and a days array of seven per-day counts starting on Sunday. The example payload in the post shows a week with 19 stars, split as 12 on Monday and 7 on Tuesday.

Other details documented in the post:

• It works for any public repository without authentication.
• Each page holds up to 30 weeks, and a caller can request up to 100 pages. Cengiz derives the needed page count from a repository's age and fetches the pages in parallel.
• Renames are handled: asking for the history of facebook/react returns the history recorded under the repository's earlier name, react/react.
• To check accuracy, Cengiz summed the weekly totals and compared them against live star counts on seven repositories, including vercel/next.js and torvalds/linux. The totals matched exactly in every case, he reports.

Rebuilding README star charts

On top of the endpoint, Cengiz built a chart generator meant to be embedded in GitHub READMEs, hosted at starhistory.link, with its source published under his GitHub account as YusufCeng1z/star-history.

Because scripts do not run inside a README, the chart has to be an image. The generator renders a Svelte component server-side into an SVG response, then animates it with plain CSS keyframes: the line is drawn using stroke-dashoffset, the fill fades in, and setting pathLength to 1000 keeps the dash behaviour consistent regardless of the path's real length. Eight visual themes are available, including an ASCII variant built from block characters and one in which a small rocket rides the curve.

Open Graph cards need PNG rather than SVG, and Cengiz notes that resvg supports neither CSS variables nor animation. The social image is therefore a separate, static SVG with literal colours, converted to PNG with resvg and fonts bundled from npm. Chart output is thinned to roughly 120 points and cached for an hour.

The workaround it replaces

Before finding the official endpoint, Cengiz experimented with the public GH Archive dataset. That data records star events by repository name rather than by repository id, so any rename orphans the older history. The effect was concrete: vuejs/core appeared to have only 51 percent of its stars, because the earlier events sat under its previous name, vuejs/vue-next. He wrote a layer to hunt down old names and verify them against the repository id, then deleted all of it once the official endpoint handled renames natively.

Why it matters

The stargazers restriction quietly broke a small ecosystem of tools that maintainers embed in project READMEs to show growth over time. The new endpoint restores that capability with an interface that is, if anything, easier to consume than the original listing: aggregated, unauthenticated for public repositories, and rename-aware.

There is also a broader lesson here for API consumers. Workarounds built on data keyed by repository name — like GH Archive — silently lose history whenever a project moves, while an official endpoint that tracks repository identity does not. The main caveat is that everything above comes from a single developer's account of a freshly shipped endpoint; details such as pagination limits and anonymous access are worth re-verifying before depending on them in production.