GitHub Dependency Graph as a Sales Signal: Find Who's Building on Your SDK

GitHub's dependency graph is visible on every public repo under the "Used by" count on the repo homepage. Click that count and you see a paginated list of public repositories that depend on your package. For API companies and SDK vendors, this is the highest-fidelity lead list on the internet — a directory of developers actively using your product (or your competitor's) in production code.

How the Dependency Graph Works

GitHub parses package manifests across all public repos: package.json (npm), requirements.txt/pyproject.toml (PyPI), Gemfile (RubyGems), go.mod (Go modules), Cargo.toml (crates.io), and more. Any public repo that lists your package as a dependency appears in your repo's dependents list.

• Coverage: all public GitHub repos with a supported manifest file
• Update frequency: near real-time — new repos appear within hours of manifest parsing
• Data available: repo name, owner (GitHub user or org), stars, language, last push date
• Access: the web UI paginates; the official REST API does not expose dependents — you must use the insights page

Accessing Dependents Programmatically

GitHub does not expose dependents via the official REST or GraphQL API, but the dependency insights page is accessible. The most practical approach uses the web UI endpoint:

import requests
from bs4 import BeautifulSoup

def get_dependents(owner: str, repo: str, max_pages: int = 10) -> list[dict]:
    """Scrape GitHub dependents list for a given repo."""
    base_url = f"https://github.com/{owner}/{repo}/network/dependents"
    headers = {"User-Agent": "Mozilla/5.0"}
    results = []
    url = base_url

    for _ in range(max_pages):
        resp = requests.get(url, headers=headers)
        soup = BeautifulSoup(resp.text, "html.parser")

        rows = soup.select(".Box-row")
        for row in rows:
            link = row.select_one("a[data-hovercard-type='repository']")
            if link:
                repo_path = link["href"].strip("/")
                owner_name, repo_name = repo_path.split("/", 1)
                results.append({
                    "owner": owner_name,
                    "repo": repo_name,
                    "url": f"https://github.com/{repo_path}",
                })

        next_btn = soup.select_one("a[rel='next']")
        if not next_btn:
            break
        url = next_btn["href"]

    return results

# Example: find every public repo depending on your package
dependents = get_dependents("your-org", "your-sdk")

Enriching Dependents into Lead Profiles

Raw dependents are repo paths. To turn them into leads, fetch each repo owner's GitHub profile:

import requests

HEADERS = {"Authorization": "Bearer YOUR_GITHUB_TOKEN"}

def enrich_dependent(owner: str) -> dict:
    """Fetch GitHub user profile for a dependent repo owner."""
    resp = requests.get(f"https://api.github.com/users/{owner}", headers=HEADERS)
    if resp.status_code != 200:
        return {}
    data = resp.json()
    return {
        "login": data.get("login"),
        "name": data.get("name"),
        "email": data.get("email"),       # public email only
        "company": data.get("company"),
        "location": data.get("location"),
        "bio": data.get("bio"),
        "followers": data.get("followers"),
        "public_repos": data.get("public_repos"),
        "type": data.get("type"),         # "User" or "Organization"
    }

# Enrich top dependents, prioritise those with public emails
leads = []
for dep in dependents[:200]:
    profile = enrich_dependent(dep["owner"])
    if profile.get("email"):
        leads.append({**dep, **profile})

Mining Competitor Dependents

The same technique applies to competitor repos. Find every public project that depends on a competitor's SDK and you have a warm list of developers in your category who have already evaluated and chosen a solution — but may be open to switching if your positioning is stronger.

# In browser: visit the competitor dependents page
https://github.com/competitor-org/competitor-sdk/network/dependents

# Then filter by:
# - Stars > 10 (active projects, not experiments)
# - Language matching your ICP (Python, TypeScript, Go)
# - Pushed recently (active maintenance = current user)

Prioritising Dependents for Outreach

Not all dependents are equal. Score them to prioritise your outreach queue:

• Stars > 100: popular open-source project — maintainer is visible and credible, outreach is worth personalising
• Stars 10–100: active smaller project — healthy user, likely a developer at a startup or SMB
• Stars < 10 + pushed recently: individual developer, likely evaluating in a personal project before company adoption
• Organisation account: company-level adoption — highest ACV potential, route to sales team
• Follower count > 500 on owner: developer influencer — worth a case study or partnership angle, not just outreach

Using GitLeads for Continuous Dependency Signal Monitoring

Manual scraping gives you a snapshot. The dependency graph changes daily as new repos add your package. GitLeads' keyword signal feature monitors GitHub continuously for references to your package name — in Issues (people asking how to use your SDK), PRs (adding your package), README files (listing your tool in their stack), and commit messages (importing your package for the first time). Combined with stargazer signals on your repo, this gives you a real-time pipeline of active adopters.

Outreach Template for SDK Dependent Leads

Subject: {their_repo} is using {your_package} — quick note

Hi {first_name},

Noticed {their_repo} is using {your_package} — thanks for building on it.

We're expanding the SDK with {new_feature} and wanted to reach out to active users first.
{One sentence on the feature and how it helps their specific use case}.

Happy to share docs or answer any integration questions. Worth a quick async exchange?

[Your name]

Related reading: how to find leads on GitHub, GitHub star tracking tools, GitHub signals for sales, find SaaS customers on GitHub, GitHub lead generation for SaaS founders, open source lead generation.