GitHub Webhook Lead Automation: Real-Time Signal Capture Without Polling

Polling the GitHub API for new stargazers or issue activity is the wrong architecture for lead capture. It introduces latency (you may miss a lead by hours), burns your rate limit, and requires infrastructure you have to maintain. GitHub webhooks are the correct primitive: the moment a developer stars your repo or opens an issue, GitHub pushes the event to your endpoint. This post covers how to receive, verify, and route those events into a lead pipeline.

What GitHub Webhook Events to Subscribe To

GitHub supports over 30 webhook event types. For lead generation, subscribe to four:

• star — fires when a user stars or unstars your repo; the sender object is your lead
• issues — fires on open, close, edit, label events; the user object is your lead candidate
• issue_comment — fires when someone comments on an issue; useful for capturing engaged commenters
• discussion + discussion_comment — if GitHub Discussions is enabled; captures long-form intent conversations

For competitor repos you do not own, webhooks are unavailable — you need to poll or use a tool like GitLeads that handles competitor monitoring. For your own repos, webhooks are the right approach.

Setting Up a Webhook Receiver

A webhook receiver is an HTTP endpoint that accepts POST requests from GitHub. The minimum viable implementation verifies the signature, parses the event type, and routes to your lead pipeline:

import crypto from 'crypto';

const GITHUB_WEBHOOK_SECRET = process.env.GITHUB_WEBHOOK_SECRET!;

export async function POST(req: Request) {
  const body = await req.text();
  const signature = req.headers.get('x-hub-signature-256') ?? '';

  // Verify signature — NEVER skip this
  const expected = 'sha256=' + crypto
    .createHmac('sha256', GITHUB_WEBHOOK_SECRET)
    .update(body)
    .digest('hex');
  if (!crypto.timingSafeEqual(Buffer.from(signature), Buffer.from(expected))) {
    return new Response('Unauthorized', { status: 401 });
  }

  const event = req.headers.get('x-github-event');
  const payload = JSON.parse(body);

  if (event === 'star' && payload.action === 'created') {
    await captureStargazerLead(payload.sender);
  } else if (event === 'issues' && payload.action === 'opened') {
    await captureIssueLead(payload.issue.user, payload.issue);
  }

  return new Response('OK', { status: 200 });
}

Enriching the Lead Before Routing

The webhook payload includes the sender's GitHub login, ID, and avatar URL — but not their email, company, bio, or follower count. You need to enrich before routing to your CRM or outreach tool:

async function captureStargazerLead(sender: { login: string }) {
  // Fetch full profile from GitHub API
  const profile = await fetch(
    `https://api.github.com/users/${sender.login}`,
    { headers: { Authorization: `Bearer ${process.env.GITHUB_TOKEN}` } }
  ).then(r => r.json());

  const lead = {
    github_username: profile.login,
    name: profile.name,
    email: profile.email,           // public email only; often null
    company: profile.company,
    bio: profile.bio,
    location: profile.location,
    followers: profile.followers,
    public_repos: profile.public_repos,
    signal: 'starred_repo',
    signal_context: 'New star on your repository',
    captured_at: new Date().toISOString(),
  };

  // Route to your CRM / outreach tool
  await pushToHubSpot(lead);
  await notifySlack(lead);
}

Rate Limiting and Queue Architecture

If your repo is popular, you may receive bursts of star events — product hunts, HN launches, and viral posts can deliver hundreds of star events in minutes. Handle this with a queue rather than inline API calls:

1. Webhook receiver: verify signature, enqueue event, return 200 immediately (GitHub will retry if you take >10 seconds)
2. Worker: dequeue, fetch GitHub profile with exponential backoff, enrich, push to destination
3. Dead letter queue: catch failed enrichments after 3 retries, alert for manual review

The GitHub API allows 5,000 authenticated requests per hour per token. For a viral launch receiving 1,000 stars per hour, enriching each lead uses 1,000 API requests — well within limits for a single token. For sustained high-volume repos, distribute across multiple tokens.

Filtering for High-Signal Leads

Not every stargazer or issue opener is a qualified lead. Apply quality filters before routing to your outreach stack:

• Follower threshold — developers with 50+ followers have demonstrated community presence
• Public repos — more than 5 repos suggests active developer, not a test account
• Account age — accounts created before 2023 are less likely to be throwaway accounts
• Email availability — only route leads with a public email if your outreach tool requires it
• Language match — if you sell a Ruby tool, prioritize leads whose top language is Ruby

When to Use GitLeads Instead of DIY Webhooks

DIY webhook pipelines work well for your own repos. But they have hard limits: you cannot receive webhooks from repos you do not own. You cannot watch competitor repos, industry repos, or keyword mentions across all of GitHub. For those signals, you need GitLeads.

GitLeads monitors any public GitHub repository (including competitor and industry repos), watches for keyword mentions in issues, PRs, and discussions across GitHub, enriches every match automatically, and pushes qualified leads to HubSpot, Slack, Smartlead, Clay, Apollo, Salesforce, and 10+ other tools — without managing webhook infrastructure.

Related: GitHub star growth as market signal, turn GitHub stargazers into leads, GitHub buying signals for sales teams, push GitHub leads to HubSpot, GitHub competitor repo monitoring.