GitHunt API v1

Search, look up, and analyze GitHub developers programmatically. GitHunt gives you millisecond access to millions of developers available on GitHub - ranked, scored, and with contact details where publicly available.

Overview Authentication Endpoints Errors Rate Limits & Quotas MCP Quickstart

Overview

The GitHunt API gives you direct access to the same developer search and ranking engine behind githunt.ai. Every account gets an API key with a monthly call quota based on their plan. All endpoints live under https://api.githunt.ai.

GitHunt continuously analyzes developer activity across GitHub, so /v1/search answers in milliseconds - no slow live crawls, no GitHub rate limits. Response payloads include a meta.dataSource field telling you how a result was served, and a meta.quota object with your current usage.

Full request/response schemas are also available as an OpenAPI 3.1 spec you can import into your own tooling.

Authentication

Generate an API key from the Account page, under the API tab. The key is shown once at creation time - store it somewhere safe, since GitHunt cannot show it to you again. Regenerating a key immediately invalidates the previous one.

Pass your key using either of these forms:

Authorization: Bearer ghk_live_...

X-Api-Key: ghk_live_...

Treat your API key like a password. Do not commit it to source control or expose it in client-side code - call the GitHunt API from your backend or a trusted server-side process.

Endpoints

Search developers

POST /v1/search

Field	Type	Required	Notes
`location`	string	Yes	City, region, or country
`role`	string	No	e.g. `backend`, `frontend`, `devops`
`skills`	string[]	No	Max 20 entries, e.g. `["go","kubernetes"]`
`languages`	string[]	No	Max 10 entries, e.g. `["Go"]`
`minExperienceYears`	number	No	0-50
`isHireable`	boolean	No	Filter to profiles flagged hireable on GitHub
`strictSkills`	boolean	No	Require all listed skills instead of any
`maxResults`	number	No	1-100, default 25
`offset`	number	No	0-200, default 0. Candidates to skip, for paging with `maxResults`
`excludeLogins`	string[]	No	Max 500 entries. GitHub logins to leave out, e.g. candidates already seen in a prior call
`excludeLocations`	string[]	No	Max 50 entries. Countries or cities to exclude, e.g. `["India"]`
`excludeUtcOffsets`	object	No	`{min, max}` hours (-12 to 14). Excludes candidates whose location resolves entirely within the band; unresolved locations are kept
`locations`	string[]	No	Max 10 entries, e.g. `["Berlin","Warsaw"]`. Merged with `location` and expanded `regions` into at most 10 combined locations (at least one of the three is required). Live GitHub crawl only covers the first location; the rest are pool-served only
`regions`	string[]	No	Max 3 entries. One of: `north-america`, `latin-america`, `south-america`, `europe`, `western-europe`, `eastern-europe`, `nordics`, `dach`, `benelux`, `iberia`, `uk-ireland`, `middle-east`, `africa`, `apac`, `east-asia`, `southeast-asia`, `south-asia`, `oceania`, `americas`, `emea`, `worldwide`. Expands to member countries and merges with `location`/`locations`. Case-insensitive; unknown names are dropped
`organizations`	string[]	No	Max 20 GitHub org logins, e.g. `["stripe","adyen"]`. Boosts candidates with employer affinity to these orgs
`sectors`	string[]	No	Max 5 entries. One of: `adtech`, `ai-ml`, `banking`, `cloud`, `cybersecurity`, `ecommerce`, `fintech`, `gaming`, `healthtech`, `media`, `mobility`, `payments`. Checked against GitHunt's employer graph
`requireOrgAffinity`	boolean	No	Default false. When true, `organizations`/`sectors` become a hard filter instead of a rank boost
`domains`	string[]	No	Max 3 entries. One of: `payments`, `healthcare`, `adtech`. Scores candidates' repos/bio against domain-specific vocabulary (e.g. core payments-processing terms, not just the word "payments")
`skillRecency`	object[]	No	Max 10 entries of `{skill, minActiveYears?, usedWithinYears?}`, ANDed. See Filtering by skill recency
`excludeList`	string	No	Name of a seen list whose logins are excluded from this search. An unknown list is an uncharged `not_found`

matchedCount is the count in this page; page with offset. If the location matches no known city or country, data.results is empty and data.locationSuggestions lists similar supported locations instead.

When organizations/sectors/domains are given, matching results also carry org_affinity and/or domain_evidence; every result may carry evidence (where matched skills were found) and inferred_utc_offset (timezone inferred from the candidate's own commits, when GitHub's location field doesn't resolve). See the OpenAPI spec for full shapes.

curl -X POST https://api.githunt.ai/v1/search \
  -H "Authorization: Bearer ghk_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "location": "Poland",
    "role": "backend",
    "skills": ["go", "kubernetes"],
    "languages": ["Go"],
    "minExperienceYears": 3,
    "maxResults": 25
  }'

{
  "success": true,
  "data": {
    "matchedCount": 25,
    "totalCount": 312,
    "results": [
      {
        "login": "example-dev",
        "score": 87,
        "profile_score": 28,
        "tech_stack_score": 35,
        "activity_score": 24,
        "github_experience": 6,
        "matching_keywords": "go, kubernetes, docker",
        "email": "dev@example.com",
        "name": "Example Developer",
        "company": "Acme Inc",
        "location": "Warsaw, Poland",
        "followers": 342,
        "bio": "Backend engineer, Go and Kubernetes",
        "profile_url": "https://github.com/example-dev",
        "hireable": "Yes",
        "last_active_date": "2026-07-18",
        "commits_per_month": 42,
        "commit_frequency_label": "Very Active",
        "semantic_commit_percentage": 78,
        "commit_message_quality_label": "Good",
        "top_repositories": [
          { "name": "k8s-operator", "stars": 1240, "language": "Go" }
        ],
        "top_oss_contributions": [
          { "repository": "kubernetes/kubernetes", "tier_label": "Elite", "commits": 15, "language": "Go" }
        ]
      }
    ]
  },
  "meta": {
    "requestId": "req_abc123",
    "dataSource": "candidate_pool",
    "quota": { "used": 12, "limit": 1000, "month": "2026-07" }
  }
}

Get a developer

GET /v1/users/{login}

Returns a flat profile for a single GitHub username. Add ?skills= with a comma-separated list (max 10) to verify recency and depth for specific languages - the response then includes a skill_checks breakdown per requested skill, drawn from the always-present skill_timeline. The response also carries evidence and inferred_utc_offset, same shapes as in search results. Use ?signals=none (or timeline / timezone; default all) to skip computing uncached signals when you only need the base profile; each signal has a server-side time budget and comes back null on timeout.

curl https://api.githunt.ai/v1/users/octocat?skills=Scala,Go \
  -H "Authorization: Bearer ghk_live_..."

{
  "success": true,
  "data": {
    "username": "octocat",
    "score": 91,
    "profile_score": 88,
    "tech_stack_score": 93,
    "activity_score": 90,
    "github_experience": 12,
    "matching_keywords": ["go", "kubernetes"],
    "bio": "Backend engineer",
    "profile_url": "https://github.com/octocat",
    "email": "octocat@example.com",
    "name": "The Octocat",
    "company": "GitHub",
    "location": "San Francisco",
    "followers": 9001,
    "blog": "https://github.blog",
    "twitter_username": "octocat",
    "created_at": "2011-01-25T18:44:36Z",
    "updated_at": "2026-06-01T09:12:00Z",
    "hireable": "Yes",
    "avatar_url": "https://avatars.githubusercontent.com/u/583231",
    "last_active_date": "2026-07-18",
    "commits_per_month": 42,
    "commit_frequency_label": "Very Active",
    "semantic_commit_percentage": 78,
    "commit_message_quality_label": "Good",
    "top_repositories": [
      { "name": "octo-cli", "stars": 1240, "language": "Go" }
    ],
    "top_oss_contributions": [
      { "repository": "kubernetes/kubernetes", "tier_label": "Elite", "commits": 15, "language": "Go" }
    ]
  }
}

The response also carries commercial_context: typed, dated evidence about commercial work plus three reasoned assessments (commercial_scala_duration, recent_commercial_scala, engineering_experience). Records come in three kinds - public_org_contribution (the candidate authored commits in a company organization's repository; contribution dates are contribution dates, never tenure), self_reported_employment (the profile company field or bio, always undated and unverified), and commit_email_domain (a hint from a non-consumer mail domain; the address itself is never exposed).

"commercial_context": {
  "schema_version": 1, "evaluated_at": "2026-09-21T09:00:00.000Z", "window_years": 3,
  "records": [ { "id": "org:acme:payments-core", "kind": "public_org_contribution",
                 "company": "Acme", "organization": "acme", "active_years": [2023, 2024, 2025],
                 "attribution": "candidate-authored (GitHub contribution attribution)",
                 "limitations": ["contribution, not employment"] } ],
  "records_truncated": false,
  "assessments": {
    "commercial_scala_duration": { "status": "unknown", "supported_months": 0, "required_months": 36,
                                    "evidence_ids": [],
                                    "reason": "no dated work-history evidence; contribution years and self-reported employers are context, not tenure" },
    "recent_commercial_scala": { "status": "unknown", "required_months": 0, "window": { "from": "2023-09-21", "to": "2026-09-21" } },
    "engineering_experience": { "status": "unknown", "supported_months": 0, "required_months": 60 }
  },
  "limitations": ["Public GitHub evidence cannot establish commercial tenure, employment dates, or private work; supported requires dated work-history evidence connecting the person, the paid work, and the dates, never contribution years or a self-reported employer."]
}

An assessment is only ever supported or unknown: absent public evidence cannot disprove private or commercial work. supported requires dated work-history evidence explicitly connecting the person, the paid work, and the dates it covers. Public GitHub data carries none, so these three assessments are unknown on every profile today, with supported_months at 0. A self-reported employer corroborated by dated contributions to that employer's organization is context for a recruiter to follow up, not tenure: the dates stay on the records, and the assessment does not count them. Account age and first public activity appear only as labelled discovery hints and never satisfy an experience requirement. The field is null if derivation fails.

Filtering by skill recency

skillRecency turns public skill activity into a search filter. Each entry needs at least one of minActiveYears (distinct calendar years with public activity in that skill, where a year counts at five or more commits) or usedWithinYears (dated activity inside a rolling window ending at the request's UTC timestamp). Both are integers from 1 to 9, entries are ANDed, and skill aliases resolve (ts, js, py, rb, kt, rs, sh, cpp, c#, golang). A malformed entry is an uncharged invalid_request, never a silently unfiltered result set.

curl -X POST https://api.githunt.ai/v1/search \
  -H "Authorization: Bearer ghk_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "location": "Poland",
    "languages": ["Scala"],
    "skillRecency": [{ "skill": "Scala", "minActiveYears": 3, "usedWithinYears": 3 }]
  }'

minActiveYears counts public activity. It is not elapsed tenure, and neither field says anything about commercial work. Candidates whose signals cannot answer the question are unknown: they are left out of the results and queued for enrichment, so a later search can judge them on evidence. That is missing evidence, not a negative finding. unknown covers four cases: no signals at all, a signal whose computation failed, an expired signal (signals are refreshed on a 30-day cycle, and one older than that no longer answers a strict filter), and a partial history whose unfetched years are exactly the ones the answer depends on. A bound that only a missing year could have met is unknown, never contradicted.

Only supported candidates occupy a slot in the per-location selection the search scores, so a candidate with evidence is never crowded out of a page by higher-activity candidates without it. Unknowns are still counted across the whole partition, and a bounded sample of them is queued for enrichment. The response reports the counts:

"meta": {
  "skill_recency": { "evaluated": 412, "supported": 18, "unknown": 96, "contradicted": 298, "partial": false },
  "exclude_list": { "name": "vami-scala-payments", "logins": 87, "truncated": false }
}

partial: true means retrieval was bounded (a capped partition or a failed pool read), so an empty page is not evidence of absence. When skillRecency is set, the search is served from the candidate pool alone: a live GitHub row carries no derived signals and could only ever be unknown.

Whenever a request carries an exclusion or skillRecency, every result also carries location_resolution:

"location_resolution": {
  "status": "resolved", "country": "Poland",
  "utc_offset": { "min": 2, "max": 2 },
  "basis": "stated_location", "observed_at": "2026-09-21T09:00:00.000Z"
}

status is resolved, ambiguous, or unresolved, with offsets computed at the run timestamp so daylight saving applies. Discovery stays permissive: ambiguous and unresolved candidates are still returned, and belong in a screening queue rather than a geographically eligible shortlist. Commit timezone is never resolved - an author-side commit offset supports discovery but cannot establish a country or a current base.

Verifying skill recency and timezone

Two signals go beyond a keyword match: whether a claimed skill is still actively used, and where a candidate actually works when GitHub's location field is empty or wrong.

Skill recency - pass skills to GET /v1/users/{login} to get a per-skill verdict from the candidate's real commit history:

curl "https://api.githunt.ai/v1/users/octocat?skills=Scala" \
  -H "Authorization: Bearer ghk_live_..."

"skill_checks": [
  {
    "skill": "Scala", "matched": true,
    "first_year": 2018, "last_year": 2026, "years_active": [2018, 2019, 2023, 2024, 2025, 2026],
    "recent_commits": 1977, "total_commits": 5000,
    "top_repos": [{ "name_with_owner": "acme/payments-core", "owner_type": "Organization", "commits": 900 }]
  }
]

Inferred timezone - every search result and user profile carries inferred_utc_offset when GitHunt has enough of the candidate's own commit timestamps to place them, independent of the (often missing or stale) GitHub location field:

"inferred_utc_offset": {
  "offset": -10, "confidence": "high", "sample_size": 34,
  "share": 0.82, "latest_commit": "2026-09-01T10:00:00-10:00"
}

Combine both with excludeUtcOffsets on /v1/search to build a search that's resilient to blank or misleading profile locations.

Evidence report

GET /v1/users/{login}/evidence

Parameter	Type	Required	Notes
`skills`	string	Yes	Comma-separated, 1-5 entries of up to 40 characters
`domains`	string	No	Comma-separated, max 3, from the same list as the search `domains` field. Without one, the core domain criterion comes back `unknown` rather than assessed

Returns the four-section evidence report for one candidate: typed evidence records with resolvable links, a supported/unknown assessment per criterion with its reason, and a targeted screening question for every unknown. Reports are built out of band under server-controlled budgets (5 repositories per candidate, 20 candidate-authored commits per repository, 12 of those commits re-read for their changed files) and cached for 14 days.

A commit subject is a discovery signal, not evidence of what changed. hands_on_backend, skill_used_recently and core_domain_recent are supported only from commits carrying inspected: true, whose inspection block shows which languages the diff touched and which core domain terms appear in the code it changed. Documentation, example, sample, demo and test files are removed first, and so are unchanged context lines, comment lines and string literals, so a README edit, an examples/ file, a comment promising the work, or an unrelated-language change cannot satisfy them. A commit whose changed lines call a payment provider's SDK is marked merchant_integration and never supports core_domain_recent or hands_on_backend. An uninspected subject match is listed under the criterion's hints and counts for nothing; the criterion stays unknown with the reason subject-level match only; changed files not inspected. coverage.commits_inspected, coverage.inspection_truncated and coverage.inspection_failed report how far the budget reached, and a failed inspection is an unknown, never a negative finding.

curl "https://api.githunt.ai/v1/users/octocat/evidence?skills=Scala&domains=payments" \
  -H "Authorization: Bearer ghk_live_..."

A cache miss returns 202, debits no monthly credits, and queues the build:

HTTP/1.1 202 Accepted
Retry-After: 60

{ "success": true, "data": { "status": "pending", "retry_after_seconds": 60, "queued": true } }

Wait at least retry_after_seconds and call again. Queueing is idempotent for ten minutes, so polling faster cannot make the build finish sooner - it only spends your daily cap. A cached report returns 200 and debits 3 credits:

{
  "success": true,
  "data": {
    "schema_version": 1,
    "evaluated_at": "2026-09-21T09:00:00.000Z",
    "window": { "from": "2023-09-21", "to": "2026-09-21", "years": 3 },
    "coverage": { "repos_scanned": 5, "repos_truncated": true, "commits_scanned": 87,
                  "commits_truncated": false, "commits_inspected": 12,
                  "inspection_truncated": true, "inspection_failed": 0,
                  "fetch_status": "complete",
                  "missing_years": [], "timeline_available": true, "stale": false },
    "criteria": {
      "hands_on_backend": { "status": "supported", "evidence_ids": ["commit:acme/payments-core:1a2b3c4"], "hints": [], "reason": "..." },
      "skill_duration_commercial": { "status": "unknown", "evidence_ids": [], "hints": [], "reason": "..." },
      "skill_used_recently": { "status": "supported", "evidence_ids": ["commit:acme/payments-core:1a2b3c4"], "hints": [], "reason": "..." },
      "engineering_experience": { "status": "unknown", "evidence_ids": [], "hints": [], "reason": "..." },
      "core_domain_recent": { "status": "supported", "evidence_ids": ["commit:acme/payments-core:1a2b3c4"], "hints": ["commit:acme/gateway:9f8e7d6"], "reason": "..." },
      "geography": { "status": "supported", "evidence_ids": ["location:stated"], "reason": "..." }
    },
    "sections": { "verified_skill_evidence": { }, "recent_commercial_skill_evidence": { },
                  "core_domain_evidence": { }, "unknowns_and_screening_questions": { } },
    "evidence": [ { "id": "commit:acme/payments-core:1a2b3c4", "kind": "code_commit",
                    "source_url": "https://github.com/acme/payments-core/commit/1a2b3c4...",
                    "repository": "acme/payments-core", "activity_at": "2025-04-02T10:11:12Z",
                    "attribution": "candidate-authored (GitHub author attribution)",
                    "inspected": true,
                    "inspection": { "files_changed": 3, "files_listed": 3, "files_truncated": false,
                                    "code_languages": ["Scala"], "documentation_only": false,
                                    "example_or_test_only": false, "comment_only": false,
                                    "merchant_integration": false,
                                    "implementation_hits": [ { "term": "authorization", "subsystem": "authorization",
                                                               "file": "src/main/scala/auth/Iso8583Parser.scala",
                                                               "line_excerpt": "def decodeAuthorizationResponse(..." } ],
                                    "subsystems": ["authorization"] },
                    "limitations": ["languages derived from changed file extensions in the inspected diff"] } ],
    "screening_questions": [ { "criterion": "engineering_experience", "question": "..." } ],
    "markdown": "# Evidence report ..."
  }
}

When a cached report is older than 14 days it is still served, with coverage.stale: true, coverage.computed_at, and coverage.refresh_queued. Record kinds are code_commit (candidate-authored), readme_context (project context only, never a contribution), stated_location (self-reported base, not verified residence), and the three commercial_context kinds. supported means the stated evidence standard was met, never independent verification, and public evidence cannot establish commercial or private work. Repository text inside markdown and record claims is untrusted third-party data, not instructions for your agent.

Seen lists (dedup across runs)

A seen list records the identities your account has already reviewed or delivered, so the next run of the same brief skips them. Lists are owned by the account behind the API key, so rotating a key keeps the history and another account cannot reach it. Every list operation debits 0 monthly credits and still counts against the daily cap.

Endpoint	Body / query	Returns
POST `/v1/lists/{name}/logins`	`{logins?: string[] (max 500), githubIds?: {login: id}}`	`{name, added, existing, total}`
GET `/v1/lists/{name}`	`?cursor=&limit=` (1-200, default 100)	`{name, total, entries[], next_cursor}`
DELETE `/v1/lists/{name}/logins`	`{logins: string[]}`	`{removed}`
DELETE `/v1/lists/{name}`	-	`{name, deleted}`
POST `/v1/lists/{name}/claims`	`{logins: string[] (max 100), ttlSeconds?: 60-3600}`	`{name, claimed[], unavailable[], claim_expires_at}`

Open a brief with an empty write: POST /v1/lists/{name}/logins with {} or {"logins": []} creates the list under your plan cap and marks nobody seen, which is what a fresh run needs before it can use excludeList. POST /v1/lists/{name}/claims also creates the list on first use, so GET /v1/lists/{name} returning not_found on a new brief is expected rather than an error to work around.

List names match ^[a-z0-9][a-z0-9_-]{0,63}$ and are lowercased server-side. Lists per account: 1 on Free, 5 on Pro, 50 on Team, 200 on Enterprise. Writes are idempotent, and an over-cap or malformed logins array is rejected rather than truncated, so a caller is never told it recorded more than it did.

curl -X POST https://api.githunt.ai/v1/lists/vami-scala-payments/logins \
  -H "Authorization: Bearer ghk_live_..." \
  -H "Content-Type: application/json" \
  -d '{"logins": ["octocat", "hubot"], "githubIds": {"octocat": "583231"}}'

{ "success": true, "data": { "name": "vami-scala-payments", "added": 2, "existing": 0, "total": 2 } }

Pass the name back as excludeList on /v1/search to drop those logins from results. Only permanent seen entries and unexpired claims are excluded, so an interrupted run's candidates are rediscoverable the moment their claim lapses. The server-side list is read up to 5000 eligible logins rather than the 500-entry client cap on excludeLogins; meta.exclude_list.truncated reports when that bound was hit. Both mechanisms work together, so existing excludeLogins callers are unaffected. Exclusions are applied before the search picks which candidates to score, so an excluded candidate never takes up a scoring slot and a rerun with a grown list keeps returning new candidates rather than an empty page.

Claims solve the concurrent-recruiter case: a claimed login is reserved for one run until it expires, entries already recorded as seen or held by another run come back under unavailable, and an interrupted run's claims lapse instead of losing the candidates. Claim before you work on a shortlist, then record delivered identities with POST /v1/lists/{name}/logins, which upgrades the claim to a permanent seen entry. An expired claim still appears under GET /v1/lists/{name} with a past claim_expires_at, so a resuming run can tell released candidates from delivered ones.

{
  "success": true,
  "data": {
    "name": "vami-scala-payments",
    "claimed": ["octocat"],
    "unavailable": [ { "login": "hubot", "state": "claimed", "claim_expires_at": "2026-09-21T09:15:00.000Z" } ],
    "claim_expires_at": "2026-09-21T09:15:00.000Z"
  }
}

Analyze a profile

POST /v1/profile/analyze

Field	Type	Required	Notes
`username`	string	Yes	GitHub login to analyze

curl -X POST https://api.githunt.ai/v1/profile/analyze \
  -H "Authorization: Bearer ghk_live_..." \
  -H "Content-Type: application/json" \
  -d '{"username": "octocat"}'

{
  "success": true,
  "data": {
    "proficiency": { "level": "Senior", "score": 72, "experienceYears": 9 },
    "emails": { "emails": [ { "address": "dev@example.com", "sources": ["profile"], "isPrimary": true } ] },
    "roleMatch": [ { "role": "backend", "displayName": "Backend", "score": 72 } ],
    "scores": { "role": "backend", "score": 72, "scores": { "profile": 25, "techStack": 30, "activity": 17 } },
    "profile": { }, "commitQuality": { }, "repositories": { }, "activity": { }, "badges": [ ], "summary": { }
  }
}

The sample above is abbreviated: profile, commitQuality, repositories, activity, badges, and summary carry the full analysis detail. See the OpenAPI spec.

Errors

All endpoints use the same error envelope:

{
  "success": false,
  "error": { "code": "quota_exceeded", "message": "Monthly API call quota exceeded" }
}

HTTP Status	Code	Meaning
400	`invalid_request`	Missing or malformed request fields
401	`unauthorized`	Missing, invalid, or revoked API key
404	`not_found`	No matching developer for the given login, or an unknown seen list name (including `excludeList` on a search, which is checked before any quota is charged)
429	`quota_exceeded`	Monthly or daily quota exceeded; includes a `Retry-After` header
500	`internal`	Unexpected server error

202 is not an error. GET /v1/users/{login}/evidence answers 202 with {"status": "pending"}, a Retry-After header, and success: true when no report is cached yet. Wait the stated number of seconds and retry the same request; it debits no monthly credits, but each attempt still counts against the daily cap.

Requests that fail validation (400) are never charged. A 5xx refunds the credit only when the failure happened before the expensive work started.

Rate Limits & Quotas

Quota is spent in credits, not flat calls. All plans are additionally capped at 2,000 API calls/day as an abuse guard, regardless of monthly quota (negotiable on Enterprise) - endpoints that cost 0 credits still count against that cap.

Endpoint	Credits
`POST /v1/search`	1
`GET /v1/users/{login}`	1
`GET /v1/users/{login}/evidence`	3 when a report is returned, 0 while pending
`POST /v1/profile/analyze`	3
`POST /v1/briefs`	25, charged once for the whole run
`GET /v1/briefs/{brief_id}`	0
`/v1/lists/*`	0

Plan	API credits / month	Rollover
Free	50 (trial)	-
Pro	1,000	-
Team	1,500	Unused credits roll over, up to one extra month's allowance
Enterprise	Unlimited	-

Every response's meta.quota includes cost (credits this call just debited) and, on Team, rollover (credits banked from last month, usable on top of limit).

MCP Server Quickstart

GitHunt ships an MCP server so you can search and analyze developers directly from Claude, ChatGPT, or any MCP-compatible AI assistant. It exposes nine tools:

Tool	What it does
`search_developers`	Pool-served search, including `skillRecency` and `excludeList`
`get_developer`	One ranked profile, with optional `skills` checks and `signals` control
`analyze_profile`	Deep live analysis of a finalist
`get_developer_evidence`	The evidence report, including the pending-and-retry case
`run_brief`	Run a whole sourcing brief server-side: searches, evidence, and the split into delivered profiles and screening leads
`get_brief`	Poll a submitted brief for its progress, then its result
`add_seen_logins`	Record reviewed or delivered identities on a seen list
`claim_seen_logins`	Reserve identities for one run so two runs cannot deliver the same person
`get_seen_list`	Read a page of a seen list to resume an interrupted run

Hosted MCP (recommended)

Connect to GitHunt's hosted MCP server and sign in with your GitHunt account in the browser - no API key to copy:

https://mcp.githunt.ai/mcp

Claude (web, Desktop, Cowork, mobile): Settings → Connectors → Add custom connector → paste the URL above, then sign in when prompted.
Claude Code: claude mcp add --transport http githunt https://mcp.githunt.ai/mcp, then run /mcp to complete the sign-in.
ChatGPT and other clients: add a remote MCP server with the URL above; the sign-in flow starts automatically.

Hosted MCP calls are billed against the same monthly API quota as REST calls, shown on your dashboard.

Local MCP (API key)

Prefer running the server yourself, or your client doesn't support remote MCP? Use the npm package with an API key from your account page:

npx githunt-mcp

Add this to your MCP client configuration (e.g. Claude Code or Claude Desktop):

{
  "mcpServers": {
    "githunt": {
      "command": "npx",
      "args": ["githunt-mcp"],
      "env": { "GITHUNT_API_KEY": "ghk_live_..." }
    }
  }
}

Need a custom plan, higher quotas, or commercial terms? Contact us.