Why Combine GitHub Signals With LinkedIn Outreach
GitHub and LinkedIn are two sides of the developer identity: GitHub shows what developers are building and evaluating; LinkedIn is where professional outreach happens. GitLeads captures the GitHub side — new stars on tracked repos, keyword mentions in issues and PRs — and Dripify automates LinkedIn connection sequences. Together, you get a pipeline that starts with real buying signals and executes outreach through the channel developers actually respond to.
The critical difference: you're not cold-prospecting random developers on LinkedIn. You're reaching people who have already shown intent — they starred your competitor's repo, mentioned a pain point keyword, or opened a GitHub issue about a problem your product solves.
How the GitLeads → Dripify Integration Works
Dripify accepts prospects via CSV import or its API. GitLeads pushes to Dripify through one of two paths:
- GitLeads webhook → Make/Zapier → Dripify API: GitLeads fires a webhook for each new lead; Make or Zapier maps the fields and calls the Dripify prospect import endpoint
- GitLeads webhook → Clay → Dripify: use Clay to enrich the GitHub lead with a LinkedIn URL, then push the completed record to Dripify
Step-by-Step: GitLeads to Dripify via Webhook + Make
- In GitLeads, set up your signal sources: add repos to Tracked Repos, configure keyword monitors in Tracked Keywords
- Go to Settings → Integrations → Webhook and create a new webhook destination
- In Make (formerly Integromat), create a new scenario with a Webhook trigger (Custom Webhook)
- Paste the Make webhook URL into the GitLeads webhook destination
- Add a Make HTTP module to call the Dripify API: POST /api/v2/prospects with the lead's LinkedIn URL and custom variables
- Map GitLeads fields: use signal_context as a Dripify custom variable for personalization in sequence messages
- Test: trigger a test signal in GitLeads and verify the prospect appears in your Dripify campaign
Webhook Payload and Dripify Mapping
// GitLeads webhook payload
interface GitLeadsWebhookPayload {
event: 'lead.created';
lead: {
github_username: string;
name: string;
email: string | null; // public GitHub email if available
linkedin_url: string | null; // if Clay enrichment added this
company: string | null;
location: string | null;
bio: string | null;
top_languages: string[];
followers: number;
signal_type: 'stargazer' | 'keyword';
signal_context: string; // e.g. "Mentioned 'redis alternative' in issue #..."
signal_repo: string; // e.g. "redis/redis"
captured_at: string;
};
}
// Dripify API call (via Make HTTP module or Zapier)
// POST https://api.dripify.io/api/v2/prospects
// {
// "linkedin_url": lead.linkedin_url,
// "first_name": lead.name.split(' ')[0],
// "campaign_id": "your-campaign-id",
// "custom_1": lead.signal_context, // "Mentioned 'redis alternative' in issue..."
// "custom_2": lead.top_languages.join(', '), // tech stack reference
// }Personalizing Dripify Sequences With GitHub Context
The power of this integration isn't just automation — it's personalization at scale. Dripify allows custom variables in sequence messages. Map the GitLeads signal_context field to a Dripify custom variable, then reference it in your connection request or follow-up:
- Connection request: "Hi {{first_name}}, saw you're building with {{custom_2}} — noticed {{custom_1}}. Would love to connect."
- Follow-up: "Your {{custom_1}} — we solve exactly that at [Company]. Worth a quick chat?"
- Signal-specific context typically doubles connection acceptance rates vs generic templates
Getting LinkedIn URLs for GitHub Leads
Dripify requires a LinkedIn profile URL, which GitHub profiles don't always include. The recommended enrichment path:
- Route GitLeads webhook to Clay first
- In Clay, add a LinkedIn enrichment step (Clay has built-in LinkedIn lookup by name + company)
- Only push records to Dripify where Clay successfully found a LinkedIn URL
- This filter typically matches 40–70% of developer leads captured by GitLeads