GitHub's 24-Request Star API Has No Names. Source Issue Authors Instead

If your go-to sourcing move was scraping every stargazer off a popular repo and emailing them, GitHub shut that move down in its June 30, 2026 changelog. GitHub's October 14 engineering post made clear the replacement won't include names: the new star history endpoint returns counts, not people. That loss is smaller than it feels. Stars were the weakest signal on GitHub, and the signals that still work lead you to better engineers.

Is GitHub bringing back the stargazer list?

No. GitHub rebuilt star history as anonymous counts, which shows the names were never part of the fix. The new /stargazers/history endpoint returns up to 30 weeks of daily star counts in one request, with no identities attached.

The timeline:

• June 30, 2026: GitHub's changelog announces that the stargazers and watchers API endpoints will be limited to repo admins and collaborators, and deprecates /users/{username}/subscriptions.
• September 4, 2026: GitHub ships a "privacy-safe" star history endpoint.
• October 14, 2026: GitHub engineers Taylor Cuilty and Sarita Iyer publish "From 2,500 requests to 24: Rebuilding star history without the stargazers," which explains the design.

The engineering post states the reasoning plainly. Tools like Star History needed counts and dates, "not usernames or other user data." Star History's founder wrote that GitHub called the original restriction an oversight, because it hadn't realized people used the stargazers endpoint that way. GitHub fixed that oversight for the charting use case only, and it fixed it with numbers. Sourcing got no replacement.

GitHub hasn't used the word "permanent." Still, if you spend engineering time on a counts-only API that cuts request volume roughly 105x, you are not planning to turn the names back on. Rebuilding the history of react/react (about 251,000 stars) used to take around 2,511 requests. Now it takes about 24.

2,511 → 24

What exactly did the June 30 restriction close?

All the routes that turned a repo into a list of people are closed, in both the API and the UI. If you're asking how to see who starred a GitHub repo you don't administer, the answer is that you can't.

Here's what's gone for anyone who isn't an admin or collaborator:

• REST stargazers endpoint. GET /repos/{owner}/{repo}/stargazers now returns 404 on any repo that has stars, according to the community tool starsift.
• GraphQL stargazers connection. It returns empty, so the usual workaround is closed as well.
• Watchers lists. These are restricted on the same terms as stargazers.
• /users/{username}/subscriptions. Deprecated, so you can no longer see which repos a user watches.
• The "You Know" stargazers view at /stargazers/you_know. Restricted in the UI.

The reaction came quickly. GitHub Community Discussion #201209, "Impacts of removing /stargazers," was opened by davidmezzetti on July 7, 2026, a week after the changelog. Community tools adapted: Daily Stars Explorer and starsift both rebuilt themselves around the new limits.

Why did GitHub treat recruiters like spammers?

GitHub restricted the lists because people were harvesting them for spam, and from GitHub's side a recruiter mass-scraping stargazers looks exactly like a spammer doing the same thing. The June 30 changelog says the lists had "increasingly been misused to collect user data for spam activities."

Consider what the classic playbook did:

1. Pick a trending repo.
2. Pull every stargazer.
3. Collect each user's public email.
4. Send the same message to everyone on the list.

The only difference between a recruiter and a spammer in that sequence is the message content. Star History's founder summed up the problem: "starring a popular repo effectively adds you to a public mailing list." Nobody who clicks a star thinks they are signing up for one.

The lesson for github stargazers sourcing goes beyond losing access to an endpoint. The tactic worked only because developers didn't realize they were opting in. A sourcing method that relies on people not noticing doesn't last.

Were stars ever a good sourcing signal?

No. A star is a free, one-click bookmark, so it was the easiest signal on GitHub to fake and the least informative one to source from. A scraped stargazer list was partly bots, and the rest told you only that someone had clicked.

The best evidence is the ICSE '26 StarScout paper, "Six Million (Suspected) Fake Stars," by Hao He, Bogdan Vasilescu, Christian Kästner and colleagues at Carnegie Mellon. Between July 2019 and December 2024 they found:

• 6.0 million suspected fake stars
• 18,617 repositories running fake star campaigns
• Flagged accounts with deletion ratios of up to 90%, about 16x higher than random GitHub repositories

6.0M

Stars also had a structural problem: they only showed the present. GitHub says the star model "was not designed as a historical event log," so when someone removes a star, the record is removed too. A scrape showed who happened to have a star at that moment, which is a poor stand-in for who uses the tool.

Most importantly, a star costs the person nothing. Bookmarking a Rust database at 11pm doesn't mean they've written Rust. You were never sourcing practitioners from that list. You were sourcing people who were curious.

Which public GitHub signals still find engineers?

Contributors, issue authors, PR reviewers and forkers all remain visible, and each one is backed by real effort in a way a star never was. Daily Stars Explorer still charts commits, PRs, issues, forks and contributors. It needs a token because those timelines run through the GraphQL API, but the data is there.

Two notes on the table:

• Forks are noisy but useful. A bare fork tells you little. A fork with commits on top of it is a much stronger sign.
• Dependents ("Used by") could be the best company-level signal of all, since they show which organizations ship the library. I haven't confirmed how much of that view remains public after the June 30 changes, so check it on your target repo before you build a process around it.

Why issue authors beat top contributors

Issue authors are often better targets than a project's top contributors. A good bug report usually means someone runs the tool in production at a company that depends on it, while top contributors are frequently already on the vendor's payroll. This is a reasoned argument rather than a measured one.

A reproducible issue that includes stack traces, version numbers and config shows that the person has integrated the tool into a real system and debugged it. That person is a practitioner at a user company, which is exactly who you want for a role on the same stack. The top committers on a vendor-backed project are often employed by the company that sells it, and they're the hardest people to move.

Stars measured curiosity. A reproducible bug report measures production experience.

PR reviewers come next. The maintainers who approve merges and the outside engineers asked to weigh in on design discussions are the people the project trusts. Reviewing takes real time, which is exactly what a one-click star never cost anyone.

Maintainers rarely say "maintainer" on their profiles

Open source maintainers almost never label themselves that way on professional profiles, so GitHub activity has to come first and profile matching second. In Refolk's index of professional profiles, only 124 US profiles and 47 German profiles have "open source maintainer" in their headline.

Compare that with GitHub itself. GH Archive tracks 63.9 million users and 331 million repositories. Fewer than two hundred self-described maintainers across both countries is a rounding error, and it means a keyword search on a professional network will miss most of the people doing the work.

The few who do use the label are informative. In the US sample they work at Okta, Docker, Microsoft, AWS, CNCF, Dynatrace, Octopus Deploy and AboutCode.org. In Germany they work at Datadog, NVIDIA, HubSpot, IBM, Dash0, Pionix and Cargoboard. They also cluster: Karlsruhe is the top German region, and Seattle plus Redmond leads the US, each with 4 of 25 sampled profiles. Most of those employers are infrastructure, cloud and observability companies, the kind that pay people to work in public.

So the hard part of sourcing developers on GitHub is matching identities across sites, not discovering people. You find a sharp issue author with the handle kv-dev, and then you have to work out that she's a platform engineer in Karlsruhe whose professional profile never mentions open source. Refolk handles that matching step: you describe the person in plain English, and the GitHub handle and the professional profile come back as one result.

A GitHub recruiting search workflow after stargazers

The replacement workflow starts from activity that took effort, narrows to recent practitioners, and only then moves to outreach. It's slower than a full stargazer scrape. The list is also much smaller and much more accurate.

1. Pick the repos your hire would actually use, not the ones trending this week. A few core libraries in your stack beat a pile of popular ones.
2. Pull recent issue authors. Filter for issues with reproductions, versions and logs. Skip "+1" comments and feature wishlists.
3. Add PR reviewers and outside contributors. Mark anyone whose email domain or bio points to the vendor, and deprioritize them unless you're specifically hiring maintainers.
4. Check forks that have commits. A fork with real work on a branch named after an internal service is an adopter.
5. Match each handle to a professional profile to get current employer, seniority and location.
6. Write to the work, not the star. Mention the specific issue or review. That shows you read it, and it's the opposite of the mass email GitHub shut down.

Step 5 is where most teams stall. Matching dozens of handles to real people, one at a time across tabs, is slow manual work for a single hard-to-fill infrastructure role, and all of it happens before anyone has replied.

What's still visible for enrichment

A few person-level views still exist, but they help you research a candidate you already know about, not build a list of strangers. One community commenter reports that you can still browse the accounts you follow and open github.com/username?tab=stars to see an individual's starred repos. That's from a single comment, so test it before relying on it.

If it holds, it's useful as context. Once you've found someone through an issue or review, their stars can show you what else they're exploring, maybe a new language or a database they're evaluating. That's a reasonable conversation starter. Running it at scale across thousands of handles would recreate the harvesting behavior GitHub restricted on June 30, so I'd keep it to the shortlist.

FAQ

How can I see who starred a GitHub repo?

Only if you're an admin or collaborator on that repo. Under the restrictions GitHub announced on June 30, 2026, the REST stargazers endpoint returns 404 to everyone else on any starred repo, the GraphQL stargazers connection comes back empty, and the "You Know" UI view is restricted. The September 4 star history endpoint returns daily counts for up to 30 weeks with no usernames.

Is the GitHub stargazers API restriction permanent?

GitHub hasn't said so explicitly. But its October 14, 2026 engineering post describes rebuilding star history so that tools get counts and dates, "not usernames or other user data," and Star History's founder says GitHub treated the charting breakage as the oversight to fix. Building a dedicated anonymous endpoint is strong evidence the names won't return.

Is it okay to contact issue authors and PR reviewers?

Yes, if you write to each person individually and reference the specific work you saw. That's what makes it different from what GitHub shut down. What drew the restriction was scraping a list and sending everyone the same message. A short note about a bug report someone filed is a conversation, not spam.