How to Find Any GitHub User Email Address

Definition

Check the profile page first, then take any commit they authored, add .patch to the URL, and read the From: header — that is where a GitHub user's email actually lives. Scavio's GitHub User Email API runs every one of those checks in a single request and flags the no-reply addresses that will never deliver.

In Depth

Check the profile first, because when it is there it takes five seconds and nothing else is needed. Open github.com/{handle} and look at the details list under the bio, next to the company and location rows: if the account holder has set a public email, it renders there as a mailto link. A minority of accounts do. GET /users/{handle} returns the same value as the email field, which is the programmatic version of that same check — and on 1 September 2026 it came back null for torvalds, gaearon, sindresorhus and tj, four of the most public developers on the platform. Do the check, expect nothing, and move on.

What that check misses is that a GitHub account has two different email addresses attached to it. The profile email is the optional one above, which almost nobody sets. The commit author email is the address configured as user.email in whatever git client made the commit. That one is baked into every commit the account has ever pushed, it is served publicly, and it is what people actually mean when they ask how to find a GitHub user's email address.

The manual route takes one request. Open any commit the person authored and append .patch to the URL: https://github.com/{owner}/{repo}/commit/{sha}.patch. GitHub serves the raw mbox patch, and the second line is a From: header carrying the name and address git recorded at commit time. No token, no login, no scraping — the walkthrough above is the whole method.

Do not use the events API for this, whatever an older tutorial tells you. The standard advice for years was to call /users/{handle}/events/public and read payload.commits[].author.email. GitHub has removed that array. Across 154 PushEvents pulled from three active accounts on 1 September 2026, not a single payload contained a commits key — the object now stops at repository_id, push_id, ref, head and before, exactly as the fourth screenshot shows. Code written against that shape does not error; it silently finds zero emails, which is a far worse failure than a 404. If an enrichment job of yours quietly stopped returning GitHub addresses, this is very likely why.

To do it at scale, search commits by author instead. GET /search/commits?q=author:{handle} returns commit objects with commit.author.email inline, so one request covers a handle rather than one request per commit:

curl -s "https://api.github.com/search/commits?q=author:torvalds&per_page=5" \
  | jq -r '.items[].commit.author.email' | sort -u

Two things bite here. The search API is rate limited far harder than the rest of GitHub — 10 requests per minute unauthenticated, 30 per minute with a token, against 60 per hour and 5,000 per hour respectively for core endpoints — so a list of a few hundred handles will spend most of its wall clock sleeping. And commit search matches on the commit author field, which means results can surface from forks and mirrors of a repository the person never touched directly. Read repository.full_name on each hit before you treat the address as confirmed.

Then there is the noreply case. If the account has "Keep my email addresses private" enabled, or the commit was made through the GitHub web editor, the address you get back is a @users.noreply.github.com one, in the modern {id}+{login}@users.noreply.github.com form or the older {login}@users.noreply.github.com. That is a real, routable-looking string and it is genuinely the account's git identity, but it will not deliver mail. Any pipeline that does not test for the users.noreply.github.com suffix will report a healthy match rate and a dead send list.

Scavio's GitHub User Email endpoint does all four checks in one call for 2 credits. It runs the commit search, falls back to fetching .patch files when a hit has no inline address, reads the profile field too, deduplicates, and flags every noreply so primary_email is only ever a deliverable address:

import requests

r = requests.post(
    "https://api.scavio.dev/api/v1/github/user/email",
    headers={"Authorization": "Bearer YOUR_API_KEY"},
    json={"handle": "torvalds"},   # username, @handle or a github.com/<user> URL
).json()

print(r["data"]["primary_email"])   # None when every address found is a noreply

for e in r["data"]["emails"]:
    # source is one of: search_commits, patch, profile
    print(e["email"], e["source"], "noreply" if e["is_noreply"] else "deliverable")

const res = await fetch("https://api.scavio.dev/api/v1/github/user/email", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
    Authorization: "Bearer YOUR_API_KEY",
  },
  body: JSON.stringify({ handle: "torvalds" }),
});

const { data } = await res.json();
const deliverable = data.emails.filter((e) => !e.is_noreply);
console.log(data.primary_email, deliverable.length);

Every address found this way is data the account holder published themselves by pushing a public commit, but publishing is not consent to be mailed. In the EU and UK the address is personal data under GDPR whatever the source, so a B2B outreach use needs a lawful basis, a disclosed identity, and a working opt-out; in the US, CAN-SPAM asks for the same last two. The uses this holds up for are the ones with an existing relationship or a legitimate interest you could defend in writing — reaching a maintainer about a security finding in their own repository, deduplicating contributors across accounts, attributing a commit in an audit, verifying that a candidate's claimed GitHub account is theirs. Scraping a repository's contributor list into a cold sequence is the use that gets a sending domain burned, and it is the one this endpoint is worst at, because a third of what comes back is a noreply address that will bounce.

Example Usage

Platforms

GitHub user email address is relevant across the following platforms, all accessible through Scavio's unified API:

• github

Related Terms