Software Engineering

GitHub optimizes star history API to reduce requests and improve privacy

Key Takeaway

GitHub replaced a heavy, identity-linked stargazer API with a specialized aggregate endpoint that provides star counts over time without exposing user identities.

Summary

GitHub has redesigned how developers access repository star history to address database performance issues and privacy concerns. The previous method required paginating through thousands of individual stargazer identities to reconstruct growth curves, which led to scraping risks and high API overhead. The new endpoint provides up to 30 weeks of daily star counts in a single request by filtering data by time before processing.

Technical shift from identity to aggregation

  • The old GET /repos/{owner}/{repo}/stargazers endpoint returned paginated lists of users, requiring thousands of requests for large repositories (e.g., 2,511 requests for react/react).
  • To prevent scraping for phishing and spam, GitHub restricted stargazer and watcher lists to repository administrators and collaborators.
  • The new endpoint returns daily star counts for up to 30 weeks in a single request.
  • Performance is improved by filtering stars by time at the database level before counting, rather than just reducing the payload size.

Why it matters

This change improves security for developers by hiding user identities while providing more efficient tools for maintainers to track project growth and release impact.

Original reference: github.blog →