How to Find GitHub Users by Company (2026 Guide)

If you sell to developers, knowing which engineers work at a target account is valuable context. GitHub is the richest public source for this data — many developers list their employer in their profile bio or company field. This guide covers every reliable method to find GitHub users associated with a specific company, including what works, what does not, and where the data gaps are.

Method 1: GitHub Search API with Company Filter

The GitHub Search API supports a `type:user` query with `org:` and `company:` qualifiers. These are different and often confused:

# Find users who list "Stripe" in their company field
curl -H "Authorization: Bearer YOUR_TOKEN" \
  "https://api.github.com/search/users?q=company:stripe+type:user&per_page=100"

# Find members of a GitHub organization (public members only)
curl -H "Authorization: Bearer YOUR_TOKEN" \
  "https://api.github.com/orgs/stripe/members?per_page=100"

# Find users by company string (case-insensitive, partial match)
curl -H "Authorization: Bearer YOUR_TOKEN" \
  "https://api.github.com/search/users?q=company:%22stripe%22&per_page=100"

The `company:` field is self-reported and unstructured. A developer at Stripe might list "Stripe", "@stripe", "Stripe Inc", "stripe.com", or nothing at all. You need to query multiple variants and deduplicate. Additionally, GitHub search results are capped at 1,000 per query — if a company like Google or Microsoft has tens of thousands of GitHub employees, you will only ever see a sample.

Method 2: GitHub Organization Member Lists

If the company has a GitHub organization (most tech companies do), you can retrieve their public member list directly. This is more reliable than the company search because membership is managed by the org admin.

import requests

def get_org_members(org_name: str, token: str) -> list[dict]:
    headers = {
        "Authorization": f"Bearer {token}",
        "Accept": "application/vnd.github+json"
    }
    members = []
    page = 1
    while True:
        resp = requests.get(
            f"https://api.github.com/orgs/{org_name}/members",
            headers=headers,
            params={"per_page": 100, "page": page}
        )
        data = resp.json()
        if not data:
            break
        members.extend(data)
        page += 1
    return members

# Then enrich each member profile
def enrich_member(login: str, token: str) -> dict:
    headers = {"Authorization": f"Bearer {token}"}
    resp = requests.get(f"https://api.github.com/users/{login}", headers=headers)
    return resp.json()

Limitations of Org Member Lists

• Only public membership is visible — many developers keep org membership private
• Contractors, consultants, and agency developers are usually not in the org
• The org name may differ from the company name (e.g., a company called "Acme Corp" might have org "acmehq" or "acme-corp")
• Large orgs can have 10,000+ members — enriching all of them is rate-limited
• Membership reflects current employment — developers who left the company may still be listed

Method 3: Signal-Based Company Identification

Instead of looking up "who works at company X", a more powerful approach is to identify developers at target companies by their activity signals. This means monitoring GitHub events (stars, issues, PRs, commit messages) and filtering the resulting leads by the company field in their enriched profile. This inverts the problem: instead of starting with a company and finding people, you start with people who are actively signaling intent and then identify which of them work at target accounts.

This is what ABM teams using GitLeads do. They set up tracking on their own repos and competitor repos, let leads flow in, and then filter the lead stream by company. The result is a list of developers at target accounts who are actively evaluating your category — a far warmer pipeline than a static "who works here" list.

Combining Methods for Maximum Coverage

• Start with org member list for known GitHub organizations — this gives you the most accurate company affiliation
• Supplement with company: field search using multiple name variants
• Cross-reference email domains during enrichment — if a developer's public email uses @company.com, that is a strong signal
• Filter by recent activity (pushed_at within 90 days) to exclude inactive accounts
• For ABM: monitor GitHub events first, then filter leads by target company list rather than pulling static member lists

Data Quality Expectations

Before building a pipeline, understand what the data actually looks like. For a mid-size tech company with 500 engineers: roughly 70–80% have a GitHub profile, about 40–50% list their employer in the company field, and about 30–40% have a public email. The org member list (if public) is the most complete single source, but typically captures only 30–60% of actual employees depending on how the company manages GitHub access.

Using GitLeads for Company-Filtered Developer Leads

GitLeads captures developer signals from GitHub in real time and enriches each lead with profile data including company, bio, email, location, followers, and top languages. You can filter your lead stream by company name to identify which inbound signal-based leads work at your target accounts — without building or maintaining any scraping infrastructure. Leads route automatically to your CRM, Slack, Clay, or any of 15+ supported destinations.