I ran 1,200 GitHub org membership lookups across 80 target accounts last quarter before touching Lusha or PDL once. The hit rate on identifying the actual technical evaluator — not the VP of Engineering who signed the PO, but the Staff Engineer who killed a deal in week three — went from 23% to 61%. The difference was two unauthenticated GitHub API calls made before I enriched a single email.
Here's the exact workflow.
Why Apollo Title Filters Miss the Person Who Actually Kills Your Deal
Apollo's title filters are built for org-chart logic. "Director of Engineering" or "VP Infrastructure" shows up clean, looks like a good ICP match, and your SDR sequences them. Meanwhile, the Staff Principal who benchmarked your product against the incumbent and found the P95 latency unacceptable never appears in your CRM at all.
When you're selling dev tooling, security products, or infrastructure software, the real evaluator is almost never the budget holder. It's the engineer who opened the trial, ran the load test, and wrote the internal Slack message that became the decision. That person's title might be "Software Engineer II" or "Platform Engineer" with no seniority signal Apollo can filter on — but their GitHub commit history and org membership tells you everything.
The competing articles I've read on OSINT for sales stop at "monitor GitHub for signals." None of them give you the actual API calls or explain how to cross-reference against LinkedIn's free tier without burning a Sales Navigator seat on an unvalidated contact. That's what this covers.
The Two GitHub API Endpoints That Do 80% of the Work
No auth token required for either of these at reasonable call volumes (60 requests/hour unauthenticated, 5,000/hour with a personal access token).
Endpoint 1: Org members list
GET https://api.github.com/orgs/{org}/members?per_page=100&page=1
This returns public members of any GitHub organization. Not every employee opts into public membership, but at mid-market tech companies (200–2,000 employees), I consistently saw 30–45% of engineering staff listed publicly. At startups, it's often 70%+.
What you're looking for in the response payload: login, html_url, and type. From the login, you pivot to the user profile endpoint.
Endpoint 2: User contribution events
GET https://api.github.com/users/{username}/events/public
This returns up to 90 days of public activity: pushes, pull requests, issue comments, stars, and — critically — forks. A fork of a competitor's repo or an adjacent open-source tool is a live evaluation signal. I'll come back to this.
Combined, these two calls give you: who works at the org (publicly), what they're actively building or evaluating, which repos they own or contribute to externally, and what their commit cadence looks like.
Cross-Referencing Org Membership Against LinkedIn Free Tier to Confirm Tenure
Here's the part most workflows skip. Just because someone is in a GitHub org doesn't mean they're still employed there. I've found ex-employees in GitHub orgs months after departure — GitHub org admin hygiene is notoriously bad.
The free LinkedIn tier still lets you view a profile directly if you have the URL, and GitHub user profiles frequently contain either a direct LinkedIn URL or enough identifying information (full name, location, personal site) to find the right profile in one search.
My process:
- Pull org members from the GitHub API
- Visit
github.com/{username}— check the bio, linked website, and any pinned repos for company affiliation signals - Search LinkedIn:
"{full name}" "{company name}"— free tier shows current title and tenure dates without a Sales Navigator seat - Confirm the position shows "Present" tenure before any enrichment spend
I ran this cross-reference on 340 GitHub org members across 12 target accounts. 41 (12%) had left the company but were still in the org. Skipping this step and going straight to Lusha or PDL would have wasted enrichment credits on dead contacts.
The confirmation takes about 90 seconds per person once you have the GitHub profile. I only do this for the subset I've pre-qualified as likely evaluators based on their repo activity.
Reading Commit Cadence as an Active Evaluation Signal
This is where the workflow gets genuinely useful and where I haven't seen other sales ops content go far enough.
The public events endpoint shows you contribution patterns. Here's what each pattern means in a sales context:
| Signal | What It Looks Like | What It Means |
|---|---|---|
| Fork of competitor OSS repo |
ForkEvent on competitor/repo in last 30 days |
Active evaluation underway |
| Star of adjacent tool |
WatchEvent on infrastructure tooling |
Building a shortlist |
| High commit cadence to integration repo | 20+ PushEvent in 14 days to a glue/config repo |
Hands-on evaluator, not spectator |
| Issue comments on competitor's tracker |
IssueCommentEvent on competitor repo |
Found pain points, comparing behavior |
| Sudden drop in commits | Activity falls from 15/week to near zero | Possible POC fatigue or vendor decision made |
The fork signal is the most reliable. I tracked 22 accounts where a GitHub org member forked a competitor's repo within 60 days of my outreach window. Of those, 18 were in an active evaluation cycle when I confirmed with the AE post-discovery. That's not a coincidence — engineers fork repos to read the code, run it locally, and understand what it does before they recommend it internally.
When I see a ForkEvent on a direct competitor from someone inside a target account, that contact goes to the top of the sequence queue regardless of their title.
Comparing the Pre-Filter Approach Against Going Straight to Enrichment
Running enrichment cold — buying a Lusha or PDL contact record without GitHub pre-filtering — costs between $0.10 and $1.20 per contact depending on your plan tier and data completeness requirements. That sounds cheap until you realize you're enriching the wrong person.
| Approach | Cost per Contact | Evaluator Hit Rate | Time per Account |
|---|---|---|---|
| Apollo title filter → Lusha enrich | ~$0.40 avg | 23% (my data) | ~5 min |
| GitHub org filter → LinkedIn confirm → Lusha enrich | ~$0.45 avg | 61% (my data) | ~18 min |
| GitHub events + fork signal → enrich top 2-3 only | ~$0.30 avg (fewer contacts enriched) | 71% (my data) | ~25 min |
The fork signal approach costs slightly less per account in enrichment spend because you're enriching two or three pre-qualified targets instead of ten title-matched contacts. The time cost is higher upfront but the downstream sequence efficiency more than compensates — I measured a 2.4x improvement in reply rate to first-touch emails when I led with a specific technical reference I could only make because I'd read their commit history.
Tools like Phantombuster can automate parts of the org member pull, and Clay can operationalize the API calls if you're running this at volume. Maigret is useful for cross-referencing a GitHub username to other platform presence when the LinkedIn profile isn't obvious.
What I Actually Use
For the GitHub API calls, I wrote a small Python script that hits the two endpoints, filters for ForkEvent and WatchEvent on a list of competitor repo names, and outputs a prioritized CSV. It takes about two hours to set up and runs in under a minute per account.
For LinkedIn confirmation, free tier manual lookup — I haven't found an automated substitute that's reliable enough for tenure confirmation without Sales Navigator.
For enrichment after the GitHub pre-filter, I use PDL for accounts where I need bulk data (better phone coverage) and Lusha for individual contacts where I want a faster single lookup. RocketReach fills gaps when both miss. If you want a more integrated workflow that combines enrichment sources and some GitHub signal parsing in one place, Ziwa is worth evaluating as one option alongside Clay for that orchestration layer.
The workflow isn't glamorous. It's two API calls, a LinkedIn tab, and a spreadsheet. But it's the reason I stopped sending "I saw you're the Director of Engineering" emails and started sending "I noticed someone on your team has been working with {specific repo} — that's exactly the use case where customers run into the X problem" emails. That specificity is only possible if you looked at the commit history first.
Top comments (0)