# GitHub restores repository star-history analytics without exposing individual stargazers GitHub has added a REST endpoint that returns historical repository star counts and timestamps without exposing who starred the project, giving analytics tools a privacy-safer replacement after GitHub restricted stargazer identity access earlier in 2026. Repository growth tools can measure when star counts changed again without rebuilding individual-user histories. The new API deliberately separates aggregate popularity data from stargazer identity, so integrations need to distinguish trend analytics from user-level community data. - Status: Active - Published: 2026-09-06T14:36:52+12:00 - Updated: 2026-09-06T14:36:52+12:00 - Categories: Web Development, Developer Tools - Tags: GitHub, privacy, repository analytics, REST API, stargazers - Canonical HTML: https://beyondthe.news/dossiers/github-star-history-api-privacy-safe-stargazer-analytics ## What changed GitHub released a new repository star-history REST endpoint on September 4, 2026. The endpoint exposes historical star counts and timestamps while withholding the identities of individual users who starred the repository. GitHub positions it as a privacy-safe way to support star-history charts and repository-growth analytics after earlier 2026 changes restricted access to stargazer listings. The API therefore restores a useful aggregate signal without recreating the user-level dataset that GitHub chose to limit. ## Why it matters Stars are a noisy popularity metric, but their history is widely used by maintainers, open-source discovery tools and competitive/repository analytics products. Tools that previously inferred history from named stargazers can move to an official aggregate surface instead of scraping or storing user identities. The trade-off is intentional: the new endpoint can answer how a repository's star count changed over time, but it cannot answer which specific accounts joined that audience. ## The new endpoint exposes the trend, not the people GitHub's new REST surface returns historical star counts and timestamps for a repository. It does not expose individual stargazer identities, making it suitable for growth curves, release-impact analysis and other aggregate trend use cases without rebuilding a list of users. ## This is a replacement path after privacy restrictions GitHub restricted access to stargazer identity data earlier in 2026. The star-history endpoint restores a supported analytics use case without reversing that privacy decision. Existing products that depend on named users still need to redesign that part of their workflow. ## Builders should separate analytics from community features A growth chart can migrate cleanly to aggregate star history, but features such as identifying new fans, enriching stargazer profiles or contacting specific accounts are outside the new endpoint's scope. Treating the two use cases separately reduces the temptation to reconstruct personal data from other sources. ## Key details - GitHub announced the privacy-safe star-history endpoint on September 4, 2026. - The API exposes historical repository star counts and timestamps. - The response does not expose the identities of individual stargazers. - GitHub describes the endpoint as a replacement analytics path after restricting stargazer identity access earlier in 2026. - The new surface supports repository-growth and trend analysis but not user-level audience analysis. ## Builder takeaways - Move star-growth charts and release-impact analysis to the official aggregate endpoint instead of storing named stargazer histories. - Do not assume the new endpoint is a drop-in replacement for features that depend on individual users; model aggregate analytics and community identity as separate capabilities. - If you retain older stargazer identity data, review whether you still need it and whether your retention/use is consistent with GitHub's current API direction. - Cache historical results where appropriate rather than repeatedly reconstructing the same repository timeline. ## What to watch - Rate limits and pagination behavior for large or old repositories. - Whether GitHub extends the same privacy-safe aggregate pattern to forks, watchers or other repository-interest signals. - Migration guidance for applications that previously depended on the named stargazer listing. - Adoption by third-party repository analytics and open-source discovery tools. ## Uncertainties - Star counts remain a weak proxy for active adoption, revenue or production use. - The new endpoint solves aggregate history, not every use case that relied on stargazer identities. - GitHub may continue changing access to social/repository metadata as privacy policy evolves. ## Sources - [New API endpoint provides privacy-safe star history data](https://github.blog/changelog/2026-09-04-new-api-endpoint-provides-privacy-safe-star-history-data/) — GitHub · primary changelog · 2026-09-04T00:00:00+12:00. Primary announcement of the aggregate star-history endpoint and privacy rationale. - [Starring - REST API endpoints](https://docs.github.com/en/rest/activity/starring) — GitHub Docs · primary documentation. Current REST documentation for repository starring surfaces.