What are GitHub buying signals?

Public developer actions on GitHub — stars, forks, pull requests, filed issues, and dependency adoption — that indicate a person or company is evaluating or already using a technology. They are a leading intent indicator for dev-tool, infrastructure, and API products.

How do I track GitHub buying signals by company?

Use the company_intent tool to rank companies whose developers are active on a given repo, org, or category, and developer_intent to find the specific developers. To make a signal actionable, resolve the developer's GitHub username to their LinkedIn with the deanon tool — billed only when it resolves.

GitHub buying signals: turn repo activity into GTM intent

A star, a fork, a pull request, a filed issue, or a new dependency on your tech is a developer telling you they're evaluating something. GitHub buying signals are those public actions — and you can pull them by repo, org, or company as tools your AI agent calls.

What counts as a GitHub buying signal

None of these are private data — they're public developer behavior on GitHub. What makes them a signal is timing and proximity to a purchase decision:

Signal	What it usually means
Stars	Awareness / shortlisting. Cheap to give, so weak on its own — strongest in aggregate or from a target account.
Forks	Hands-on evaluation. Someone copied the code to run or modify it.
Pull requests	Deep engagement. A contributor invested enough to change your project (or a competitor's).
Issues	Active use with friction. People file issues against tools they're actually running.
Dependency adoption	Adoption itself. A repo or org adding your package (or a competitor's) to its manifests.

Caveat: GitHub activity skews toward developers and OSS-heavy companies. It is a leading indicator for dev-tool, infra, and API products — not a universal intent source for every B2B category.

How to pull them

DataForGTM exposes two tools for this, scoped by repo, org, or category:

developer_intent — find individual developers showing GitHub buying signals for a repo, org, or technology category.
company_intent — rank companies whose developers are active on the tech you sell (or a competitor's).

The point of person- and company-level signals is acting on them. A raw GitHub username isn't sellable to a GTM team, so the deanon tool resolves a username to the real person's LinkedIn profile — charged 2 credits (~$0.30) only on a hit, free on a miss.

From signal to person

Once developer_intent surfaces a username, resolve it to a real person:

# Resolve a developer who starred/forked your repo → LinkedIn
curl -X POST https://dataforgtm.ai/api/v1/deanon \
  -H "Authorization: Bearer $DATAFORGTM_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"githubUser":"torvalds"}'

Everything is agent-callable over MCP or plain OpenAPI with a bearer key — no dashboard, no seat, prepaid pay-per-use.

Start

Start a trial and get an API key, or read the OpenAPI spec. Signal lookups are unmetered; you only pay when deanon resolves a person.

FAQ

What are GitHub buying signals?: Public developer actions on GitHub — stars, forks, pull requests, filed issues, and dependency adoption — that indicate a person or company is evaluating or already using a technology. They're a leading intent indicator for dev-tool, infrastructure, and API products.
How do I track GitHub buying signals by company?: Use the company_intent tool to rank companies whose developers are active on a given repo, org, or category, and developer_intent to find the specific developers. To make a signal actionable, resolve the developer's GitHub username to their LinkedIn with the deanon tool — billed only when it resolves.