Documentation navigation
GET /v1/developers/search

Search developers

Access
Authenticated
search:read
Cost
Free
Rate limit
30 / minute per account
Quota
None

Search GitHub developers semantically and get one page back, enriched to the depth you ask for.

Reach filters. requireEmail, requireLinkedin and requireLocation all default to false — search stays open by default so a plain query returns the full ranked pool and fills your limit. Opt in (requireEmail=true) only when you want to narrow to people we can reach. All three only FILTER; none returns an address.

Reading a result. Each result is a flat identity object (id, login, name, avatarUrl, hasEmail, hasLinkedin, hasLocation) plus a keyed details object nested by namespace — details.githubProfile.core, details.githubProfile.repos, details.score.cracked, details.identity.linkedin / details.identity.experience / details.identity.education, details.contact.socials / details.contact.location / details.contact.emails, details.github.garden. The resolved location object rides details.contact.location at enriched; the spine carries only the free hasLocation flag. A namespace and its members appear only when resolved; absent details are omitted entirely. Per-repo subject/technology tags fold onto details.githubProfile.repos[] when tags.repos was resolved. Nothing is duplicated between the identity fields and the details. Rows arrive best-match first: the order is the ranking, there is no per-row score to read. match.repos is why this person matched; match.status: "unattributed" means the lane that answered cannot attribute, not that the match is weak. match is search-only — the id-based routes carry no query and omit it.

Short pages. A page can come back shorter than limit, and countStatus is how you read it. {"kind":"exact"} means you got the full ask. {"kind":"short"} carries requested, returned and a shortfallReason, and only corpus claims the index is exhausted: filter_attrition, call_budget, coverage and lane_window all mean more may exist, so ask again with the cursor. A page served from cache can omit countStatus entirely.

Query parameters

  • q string

    Free-text description of who you are looking for, matched semantically. This carries the intent; every other parameter narrows it. Either `q` or at least one narrowing parameter is required.

    max 500 chars
  • depth string default: "core"

    How much data comes back per developer. `core`: the profile (login, name, company, followers, top repositories with descriptions and languages), the query `match` block (search only) and the cracked score. `enriched`: all of core, plus the resolved LinkedIn identity, social links and the resolved `location` object. `deep`: all of enriched, plus the contribution garden — the full contribution heatmap, by far the largest block on the wire, which is why it is its own tier: stay on core or enriched when you do not need it. Depth is how far OUT a tier reaches (core = what we already hold on GitHub, enriched = external identity, deep = live GitHub). Qualitative extras are NOT depth tiers — the AI-written summaries and the per-repo subject/technology tags are separate à-la-carte facets, resolved once and cross-account cached.

    coreenricheddeep
  • facets string

    À-la-carte facet keys to resolve ON TOP OF the depth tier, comma-separated, at most 5 — e.g. `tags.repos` to get the deterministic per-repo subject/technology tags folded onto `details.githubProfile.repos[]`. An unknown or non-public key is a 400; a facet already inside the chosen tier is a no-op.

    max 605 chars
  • garden string
    fullsummary
  • limit integer default: 25

    Developers per page, 1-250 (default 25). A large page's tail is less finely ranked, so ask for what you will use.

    min 1, max 250
  • cursor string

    Opaque cursor from a previous response. Lane-scoped: do not construct, parse or reuse across different queries.

    max 256 chars
  • lang string

    Programming languages a developer must have demonstrated, e.g. `go,rust`. Filters on EVIDENCE, not on absence: a developer we hold no language data for is not excluded by this parameter.

    max 2420 chars
  • skills string

    Demonstrated abilities, matched semantically against what the person has actually built. Use `lang` when something is genuinely mandatory.

    max 2420 chars
  • country string

    Countries to restrict to, e.g. `united states,canada`.

    max 2420 chars
  • city string

    Cities to restrict to, matched against our geocoding of the self-reported location, e.g. `san francisco,berlin`. Like `country`, it filters on EVIDENCE: a developer we hold no location for is not excluded.

    max 2420 chars
  • state string

    States or regions to restrict to, e.g. `california,ontario`. Subdivisions resolve mostly from the LinkedIn overlay — the GitHub geocoder rarely returns a reliable state — so this restricts to the linked-profile minority we hold, expect small pages, like `requireLinkedin`.

    max 2420 chars
  • company string

    Companies the person works at NOW.

    max 2420 chars
  • excludeCurrentCompanies string

    Companies to EXCLUDE — drop developers who currently work at any of these, e.g. exclude your own competitors. A real push-down (not a post-filter).

    max 2420 chars
  • pastCompanies string

    Companies the person used to work at. Resolved from the LinkedIn overlay, so it restricts to the linked-profile minority we hold — expect small pages, like `requireLinkedin`. It matches the FULL employment history, so a row that matched `google` can still show a different employer in `details.githubProfile.core.organization` (that field carries their GitHub-listed current company). Pass `depth=enriched` to see the matched employer in `details.identity.experience`.

    max 2420 chars
  • schools string

    Schools/universities the person attended, e.g. `stanford university,mit`. Resolved from the LinkedIn overlay, so it restricts to the linked-profile minority we hold — expect small pages, like `requireLinkedin`. It matches the FULL education history, so a row that matched `mit` can still show a different school in `details.githubProfile.core.university` (that field carries only their most recent institution). Pass `depth=enriched` to see the matched school in `details.identity.education`.

    max 2420 chars
  • titles string

    Job titles to aim at, e.g. `staff engineer,engineering manager`. Resolved from the LinkedIn overlay, so it restricts to the linked-profile minority we hold — expect small pages, like `pastCompanies`/`requireLinkedin`.

    max 2420 chars
  • industries string

    Industries the person works in, e.g. `fintech,healthcare`. Resolved from the LinkedIn overlay, so it restricts to the linked-profile minority we hold — expect small pages, like `requireLinkedin`.

    max 2420 chars
  • peerCompanies string

    Companies to treat as reference points for "companies like these", rather than as an allowlist in themselves. Resolved from the LinkedIn overlay, so it restricts to the linked-profile minority we hold — expect small pages, like `requireLinkedin`.

    max 2420 chars
  • companySize string

    Size band of the person’s CURRENT employer: `1-50`, `51-200`, `201-2000` or `2000+`. Resolved from the LinkedIn overlay, so it restricts to the linked-profile minority we hold — expect small pages, like `requireLinkedin`.

    1-5051-200201-20002000+
  • experienceTier string

    A coarse experience band to aim at: `early`, `upToSenior`, `senior` or `all`. Resolved from the LinkedIn overlay, so it restricts to the linked-profile minority we hold — expect small pages, like `requireLinkedin`.

    earlyupToSeniorseniorall
  • yoeMin integer | null

    Minimum years of experience. Resolved from the LinkedIn total-experience overlay column, so a profile with no overlay value falls outside the band — it restricts to the linked-profile minority we hold. Pairs with `yoeMax`.

    min 0
  • yoeMax integer | null

    Maximum years of experience. Pairs with `yoeMin`; same LinkedIn-overlay restriction.

    min 0
  • openToWork string default: "false"

    Return only developers flagged open-to-work on their LinkedIn profile. Requires the LinkedIn overlay, so it restricts to the linked-profile minority we hold. **Defaults to `false`** (no filter).

    truefalse
  • repos string

    Seed repositories as `owner/name`. Finds developers who build things comparable to these.

    max 1210 chars
  • minFollowers integer | null

    Minimum GitHub follower count.

    min 0
  • minCracked integer | null

    Floor on the cracked score (0-100, the same standing as `details.score.cracked.crackedScore` / devrank), measured against the whole indexed GitHub population. A tunable reputation gate: `minCracked=90` keeps only the top tier. Pairs with `maxCracked` to carve a band. Note this is a FLOOR that filters the fetched window, not a global sort — there is no "rank by cracked" order today (the provider does not index the score as sortable).

    min 0, max 100
  • maxCracked integer | null

    Ceiling on the cracked score (0-100), the upper bound of a cracked RANGE — pair with `minCracked` as the floor. E.g. `minCracked=60&maxCracked=85` targets strong-but-not-famous developers, skipping the very top. Like `minCracked`, this filters the fetched window, it is not a sort.

    min 0, max 100
  • minFollowing integer | null

    Minimum number of accounts the developer FOLLOWS (the indexed `following` column). A real index filter on the GitHub User lane.

    min 0
  • maxFollowing integer | null

    Maximum number of accounts the developer follows. Pairs with `minFollowing` to band the `following` column.

    min 0
  • minRepos integer | null

    Minimum number of public repositories owned (the indexed `repo_count` column).

    min 0
  • maxRepos integer | null

    Maximum number of public repositories owned. Pairs with `minRepos`.

    min 0
  • minStars integer | null

    Minimum TOTAL stars across the developer’s repositories (the indexed account-level `total_stars` column, distinct from a single repo’s stars).

    min 0
  • maxStars integer | null

    Maximum total stars across the developer’s repositories. Pairs with `minStars`.

    min 0
  • pushedAfter string

    Freshness floor: keep only developers whose most recent push (`last_pushed_at`) is on or after this `YYYY-MM-DD` date.

    max 10 chars
  • pushedBefore string

    Keep only developers whose most recent push (`last_pushed_at`) is on or before this `YYYY-MM-DD` date. Pairs with `pushedAfter`.

    max 10 chars
  • orgs string

    GitHub organizations associated with the developer, e.g. `vercel,cloudflare`. Any-of, a hard filter on the indexed `orgs` set. This can include organizations they contribute to, not only ones they are a public member of.

    max 2420 chars
  • subjects string

    Subject tags the developer must work in, e.g. `distributed-systems,cryptography` — any-of, a HARD filter on the indexed `subjects` set. Distinct from a semantic `q`, which is a soft aim.

    max 2420 chars
  • techs string

    Technologies the developer must have tagged, e.g. `react,rust` — any-of, a HARD filter on the indexed `technologies` set. Distinct from `lang` (repo-language evidence) and `skills` (semantic aim).

    max 2420 chars
  • tier string

    The cracked-tier label to require (the indexed `crackedTier` column): one of `developing`, `intermediate`, `advanced`, `expert`, `elite` (case-insensitive). A coarser gate than `minCracked`/`maxCracked`.

    max 32 chars
  • employer string

    Employers INFERRED from GitHub signal (the indexed `inferred_employer_name` column), any-of. Distinct from `company` (the LinkedIn-overlay current employer), and does not narrow to the linked-profile minority.

    max 2420 chars
  • hideHighProfile string default: "false"

    Suppress very high-profile accounts, which otherwise dominate a ranking without being realistic hires. A GitHub-lane bias, no LinkedIn overlay needed. **Defaults to `false`** (no suppression).

    truefalse
  • sort string default: "relevance"

    Result order. `relevance` (default) is best-match-first. `cracked` orders by cracked score (devrank, strongest first) and `followers` by follower count (highest first) — reputation/reach sorts that need no query. On the GitHub User lane these become a true corpus-wide order once the provider indexes the attributes; until then they reorder the fetched page. A non-relevance sort binds only when the query routes to the GitHub User lane. Prefer `sortBy`, which covers every sortable numeric facet; when both are sent `sortBy` wins.

    relevancecrackedfollowersfollowingtotal_starsrepo_countcontributions_last_yearlast_pushed_at
  • sortBy string

    Order results by one numeric developer facet, corpus-wide on the GitHub User lane: `crackedScore` (devrank), `followers`, `following`, `total_stars`, `repo_count`, `contributions_last_year`, or `last_pushed_at` (most recently active first). Every facet sorts strongest/highest/most-recent first — there is no direction knob, the index fixes it per facet. Absent = `relevance` order (unchanged). Binds only on the GitHub User lane; other lanes stay relevance-ordered. Takes precedence over `sort` when both are sent.

    crackedScorefollowersfollowingtotal_starsrepo_countcontributions_last_yearlast_pushed_at
  • requireEmail string default: "false"

    Return only developers we hold an email for (i.e. `hasEmail: true`). **Defaults to `false`** — search stays open like every other filter, so a plain query returns the full ranked pool and fills your `limit`; opt in with `requireEmail=true` when you only want people you can email. FILTERS only; it never returns an address.

    truefalse
  • requireLinkedin string default: "false"

    Return only developers we hold a LinkedIn match for (i.e. `hasLinkedin: true`). **Defaults to `false`** — most searches should stay open, since we only hold a LinkedIn match for a minority of developers and requiring one narrows the pool sharply. Set `true` when resolved identity/company matters more than reach.

    truefalse
  • requireLocation string default: "false"

    Return only developers we resolved a location for (i.e. `hasLocation: true`). **Defaults to `false`**. Set `true` when you can only act on people you can place. FILTERS only; the `hasLocation` flag is free on every row and the resolved `location` object rides `details.contact.location` at `enriched`.

    truefalse
  • repoLimit integer default: 4

    How many top repositories to return per developer in `details.githubProfile.repos`, 1-12 (default 4). The default is kept small because the full list reads long and `match.repos` already answers "why they matched".

    min 1, max 12
  • exclude string

    Developer ids to leave out, comma separated. Send back what you already have when paging so a short page does not repeat itself.

    max 8000 chars

Responses

  • 200 One page of developers, enriched to the requested depth
    • cursor string | null required

      Opaque continuation token: pass it back as `cursor` for the next page. Null means the engine has no continuation left for this query. Do not parse it or construct one.

      max 256 chars
    • cached boolean required

      True when this page was served from a cached result set rather than a fresh engine run. A cached page can be missing the newer envelope fields and can carry `evidence.matchStatus: unattributed`. Caching does not change what you are charged: search is billed per developer returned either way.

    • countStatus one of

      Whether you got the number of results you asked for, and if not, why. Never padded and never silently short.

    • results array of PublicSearchDeveloper required

      The developers on this page, best-match first. The order IS the relevance ranking. Each carries a `match` block attributing the query to their repositories.

      max 250 items
      • id string required

        The stable GitHub numeric id for this developer. Immutable (unlike the login) — this is the handle to pass to every other endpoint.

        max 64 chars
      • login string required

        The GitHub handle as of the last snapshot. Display it, do not key on it: handles are renameable and reusable.

        max 200 chars
      • name string | null required

        Display name as the developer set it on GitHub. Null when they set none.

        max 200 chars
      • avatarUrl string | null required

        GitHub avatar image URL. Null when absent.

        max 2048 chars
      • hasEmail boolean required

        Whether we hold at least one email address for this developer. It says we have an address on file, not that the address works — we do not check deliverability. The addresses themselves are never returned by a search or a base profile read: this boolean is the free signal, and the paid `contact.emails` facet is the only way to get them. Use `hasEmail` on a search request to filter to developers we hold an address for, without paying.

      • hasLinkedin boolean required

        Whether we hold a LinkedIn match for this developer — i.e. whether `enriched` will return `identity.*` and `contact.socials` for them. Available on the same base row as `hasEmail`: read both to decide what depth is worth requesting.

      • hasLocation boolean required

        Whether we hold any resolved location for this developer (from LinkedIn or a geocoded GitHub string). A free presence flag alongside `hasEmail`/`hasLinkedin`. The resolved `location` OBJECT rides `details.contact.location` at `enriched` (like the LinkedIn URL), not on the spine. Filter on it with `requireLocation=true`.

      • details PublicDetails required

        Every detail about this developer beyond the identity spine, as a KEYED object nested by namespace. A namespace and a member appear only when resolved; absent details are omitted entirely. The set grows with depth: `core` fills `githubProfile.*` and `score.cracked`; `enriched` adds `identity.*`, `contact.socials` and `contact.location`; `deep` adds `github.garden`. À-la-carte: `tags.repos` folds onto `githubProfile.repos[]`, the emails route fills `contact.emails`.

        • githubProfile object

          The free GitHub profile: `githubProfile.core` (bio, org, languages, snapshot counts) and `githubProfile.repos`. Named for its source — everything here comes straight from GitHub.

          • core object

            bio, currentRole, organization, university, languages, joinedAt, followers, following, totalStars.

          • repos array of ProfileRepoWithTags

            Top repositories (default 4), with `owned`/`commits` and, when resolved, `subjects`/`technologies` (`tags.repos`) and a plain-English `summary`/`themes` (`ai.repo_summaries`) folded on. The AI blurbs live HERE, on the repos shown, not in a separate list.

            • name string required

              The repository name alone, without the owner (`linux`).

              max 200 chars
            • fullName string required

              GitHub `owner/name`. This is the join key: an evidence repo and a profile repo describing the same repository carry the same `fullName`.

              max 200 chars
            • description string | null required

              The repository's own GitHub description, verbatim. Null when it has none.

              max 5000 chars
            • language string | null required

              GitHub's primary language for the repository. Null when GitHub reports none (an empty or docs-only repo); never inferred from the code.

              max 200 chars
            • stars integer required

              Stargazer count at the time this profile was snapshotted, not at request time.

              min 0, max 100000000
            • commits integer

              How many commits THIS developer authored to this repository over the trailing year. This is the difference between a project they wrote and a project they landed one drive-by fix in — a 385k-star repository with 4 of their commits is not their work. Absent when no commit signal was captured; 0 means none in the trailing year, which for older dormant work is not the same as none ever.

              min 0, max 100000000
            • owned boolean

              True when the repository sits under the developer's own account, false when it is someone else's (an organisation's or another person's) and they are a contributor to it. This is the difference between "they built this" and "they committed to this", and it is the ONLY honest basis for crediting a repository's stars to a person. Absent when no ownership signal was captured; treat absent as unknown, never as false.

            • url string required

              The public github.com URL of the repository.

              max 2048 chars
            • subjects array of string

              Subject/domain tags for this repository. Present only when `tags.repos` was resolved and this repo carried tags.

            • technologies array of string

              Technology tags for this repository. Present only when `tags.repos` was resolved and this repo carried tags.

            • summary string

              A one-line, plain-English blurb on what this repository is, written for a non-technical reader. Present only when `ai.repo_summaries` was resolved and the model could describe this repo. The summaries are folded ONTO the repos you see here — there is no separate list — so what is described is exactly what is shown.

            • themes array of string

              A few short themes the AI drew from this repository. Present alongside `summary` when `ai.repo_summaries` was resolved.

        • score object

          The cracked score (`score.cracked`).

          • cracked object

            crackedScore, tier.

        • identity object

          The resolved external identity (`enriched`): `identity.linkedin`, `identity.experience`, `identity.education`.

          • linkedin object

            The resolved LinkedIn identity scalars (linkedin, headline, title, company, seniority, expertise, location).

          • experience array of object

            Employment history, newest first. Present only when non-empty.

            • title string | null

              Job title.

              max 200 chars
            • company string | null

              Employer name.

              max 200 chars
            • startDate string | null

              Start date exactly as the source rendered it. Free text, not normalised.

              max 200 chars
            • endDate string | null

              End date, same unnormalised free-text form. Null on a current role.

              max 200 chars
            • current boolean | null

              The source's own "still there" flag.

          • education array of object

            Education history. Present only when non-empty.

            • school string | null

              Institution name.

              max 200 chars
            • degree string | null

              Degree awarded.

              max 200 chars
            • fieldOfStudy string | null

              Field of study.

              max 200 chars
            • startDate string | null

              Start date as the source rendered it.

              max 200 chars
            • endDate string | null

              End date as the source rendered it.

              max 200 chars
        • contact object

          Contact channels: `contact.socials` (enriched), `contact.location` (enriched), `contact.emails` (the emails route).

          • socials object

            github, linkedin social links.

          • emails array of string

            Every address we observe for this developer. Present only when we hold at least one, resolved via the emails route.

          • location object | null

            Where this developer is, resolved once and LinkedIn-preferred: `source` says whether the clean city/country came from their LinkedIn (`linkedin`) or from geocoding their GitHub location string (`github`). Present at `enriched`+ whenever `hasLocation` is true — the spine carries only the `hasLocation` flag. Note the GitHub geocode is rough (it often drops a country string into `city`); trust `source: "linkedin"` over `"github"`.

            • raw string | null required

              The location string exactly as the developer typed it on GitHub ("SF / remote").

              max 200 chars
            • city string | null required

              City resolved from `raw` by geocoding. Null when `raw` was empty or unresolvable.

              max 200 chars
            • state string | null

              The country subdivision (US state, province, region) as a full name, e.g. "Ohio". Present only from the clean LinkedIn overlay, for the developers we hold a match for. Absent otherwise: the GitHub geocoder does not reliably resolve it (so we do not surface its guess), and it is legitimately absent for city-states and metro-only profiles.

              max 200 chars
            • country string | null required

              Country resolved from `raw`. Null when `raw` was empty or unresolvable.

              max 200 chars
            • source string

              Where the resolved city/country came from: `linkedin` when our LinkedIn overlay supplied it (clean, self-reported on LinkedIn), `github` when it is geocoded from the GitHub `raw` string. Most developers have no LinkedIn match, so `github` is the common case and its city/country are often sparse. Absent on unresolved payloads.

              linkedingithub
        • github object

          The live-GitHub block (`deep`): `github.gardenSummary` by default, or the full `github.garden` with `garden=full`.

          • garden object

            The full contribution heatmap: every day’s count for the trailing year. Only with `garden=full`.

          • gardenSummary GardenSummary

            The contribution garden as a compact read (the default `garden=summary`): totals, active days and weeks, the last 90 days, per-month counts.

            • from string required

              First day of the garden window, `YYYY-MM-DD`, inclusive.

            • to string required

              Last day of the garden window, `YYYY-MM-DD`, inclusive.

            • total integer required

              Public contributions across the window.

            • activeDays integer required

              Days in the window with at least one contribution.

            • activeWeeks integer required

              Distinct weeks in the window with at least one contribution. Steady contributors score close to 52.

            • last90Days integer required

              Contributions in the 90 days ending on `to`.

            • lastActiveDay string | null required

              The most recent day with a contribution, `YYYY-MM-DD`. Null when the window is empty.

            • byMonth object required

              Contributions per calendar month, `YYYY-MM` → count. Months with none are omitted.

            • fetchedAt string required

              When the underlying garden was read from GitHub, as an ISO 8601 instant.

            • followers integer | null required

              Current GitHub follower count, live. Null on a garden cached before live stats existed.

            • totalStars integer | null required

              Stars on repositories they OWN, live. Null on a garden cached before live stats existed.

        • ai object

          À-la-carte AI prose. `person_summary`/`repo_summaries` come from the `/developers/summaries` route or `facets=ai.person_summary,ai.repo_summaries` on any route. `match_rationale` comes from `facets=ai.match_rationale` on SEARCH — it is judged against your `q`. Compute is async: each member carries a `status` — `ok` or `pending` (with `retryAfterMs`: wait that long, then re-fetch this call once — the value is computed once and cached, so the retry returns fast). On `ok`, `person_summary` and `match_rationale` carry their `value` here; `repo_summaries` instead folds its blurbs onto `githubProfile.repos[]` and carries status only. Read status before value.

          • person_summary object

            A short, varied one-liner on who this developer is.

            • status string required
              okpending
            • value object
            • retryAfterMs number

              On `pending` only: milliseconds to wait before re-fetching this call. The value is compute-once/cached, so the retry returns `ok` fast once it lands.

          • repo_summaries object

            Poll marker for the per-repo AI blurbs. The blurbs themselves fold onto `githubProfile.repos[].summary`/`.themes` (one-to-one with the repos shown), so this cell carries only `status`: `ok` means the blurbs are on the repos, `pending` (with `retryAfterMs`) means re-fetch. There is no `value` here.

            • status string required
              okpending
            • value object
            • retryAfterMs number

              On `pending` only: milliseconds to wait before re-fetching this call. The value is compute-once/cached, so the retry returns `ok` fast once it lands.

          • match_rationale object

            Whether and why this developer matches the search query, judged against it. SEARCH ONLY (there is no query to judge against on an id lookup). `value` is `{ matched, reasons? }`: a real match is `{ matched: true, reasons: ["Currently Staff Engineer at Stripe on payments", "Maintains a Go ISO-20022 library", "8 years shipping Go"] }` — a list of short, positive, recruiter-facing bullets (repos, languages, LinkedIn role/company, organisation, location, tenure). A weak/non-match is `{ matched: false }` (no reasons — an honest verdict, not a manufactured one). Check `matched` before reading `reasons`.

            • status string required
              okpending
            • value object
            • retryAfterMs number

              On `pending` only: milliseconds to wait before re-fetching this call. The value is compute-once/cached, so the retry returns `ok` fast once it lands.

      • match DeveloperMatch required

        Query attribution for this result: the matched repositories and whether the lane could attribute at all.

        • repos array of MatchRepo required

          The repositories that connect this developer to your query. Empty whenever `status` is `unattributed`.

          max 12 items
          • fullName string required

            GitHub `owner/name`. The join key onto `developer.repos[].fullName`, so you can match an evidence repo back to the profile repo it refers to.

            max 160 chars
          • stars integer required

            Stargazer count at retrieval time. 0 also means "the source returned no count", so do not read 0 as proof the repo is unstarred.

            min 0, max 100000000
          • language string | null

            GitHub’s primary language for the repository. Null when none was returned; never inferred from the code. Absent on pages produced before this field existed.

            max 200 chars
          • role string | null

            This person’s relationship to the repository, and it is deliberately conservative. `owner` means the repository sits under THEIR namespace. `contributor` means everything else, including the person who wrote most of the code in someone else’s or an organisation’s repository — a top committer on a company repo is a `contributor`, so do not read `contributor` as "minor" or `owner` as "wrote it". Null means the lane that produced this row genuinely cannot tell; absent means an older producer did not emit the field.

            ownercontributor
        • status string required

          Whether `repos` genuinely answers "why did this person come back for my query". `attributed` = it does. `unattributed` = the lane that answered cannot attribute repositories to the query, and `repos` is empty.

          attributedunattributed
  • 400 No query and no narrowing parameter
    • code string required

      Stable machine-readable error code. Branch on this, never on the numeric status.

      bad_requestunauthorizedsignature_requiredpayment_requiredforbiddennot_foundconflictgonepayload_too_largeunprocessable_entitytoo_many_requestsinternal_errornot_implementedbilling_unavailablenot_contactablemailbox_link_unavailablemailbox_requiredmail_engine_unavailablewebhook_publisher_unavailabledatabase_unavailableclient_errorbuild_failed
    • message string required

      Human-readable explanation of the refusal.

    • status integer required

      The HTTP status code, repeated in the body.

    • remedy object

      A self-serve path forward, when one exists (a 402 points at how to restore access).

      • kind string required

        What kind of remedy this is, so a client can route it: whether the caller can clear the condition through the API, or a person must act in the web app.

        topupconnect_mailbox
      • url string required

        Where to go to clear the condition: an API path, or a web app page when only a person can.

  • 401 Missing or invalid API key
    • code string required

      Stable machine-readable error code. Branch on this, never on the numeric status.

      bad_requestunauthorizedsignature_requiredpayment_requiredforbiddennot_foundconflictgonepayload_too_largeunprocessable_entitytoo_many_requestsinternal_errornot_implementedbilling_unavailablenot_contactablemailbox_link_unavailablemailbox_requiredmail_engine_unavailablewebhook_publisher_unavailabledatabase_unavailableclient_errorbuild_failed
    • message string required

      Human-readable explanation of the refusal.

    • status integer required

      The HTTP status code, repeated in the body.

    • remedy object

      A self-serve path forward, when one exists (a 402 points at how to restore access).

      • kind string required

        What kind of remedy this is, so a client can route it: whether the caller can clear the condition through the API, or a person must act in the web app.

        topupconnect_mailbox
      • url string required

        Where to go to clear the condition: an API path, or a web app page when only a person can.

  • 402 Your plan does not include this capability
    • code string required

      Stable machine-readable error code. Branch on this, never on the numeric status.

      bad_requestunauthorizedsignature_requiredpayment_requiredforbiddennot_foundconflictgonepayload_too_largeunprocessable_entitytoo_many_requestsinternal_errornot_implementedbilling_unavailablenot_contactablemailbox_link_unavailablemailbox_requiredmail_engine_unavailablewebhook_publisher_unavailabledatabase_unavailableclient_errorbuild_failed
    • message string required

      Human-readable explanation of the refusal.

    • status integer required

      The HTTP status code, repeated in the body.

    • remedy object

      A self-serve path forward, when one exists (a 402 points at how to restore access).

      • kind string required

        What kind of remedy this is, so a client can route it: whether the caller can clear the condition through the API, or a person must act in the web app.

        topupconnect_mailbox
      • url string required

        Where to go to clear the condition: an API path, or a web app page when only a person can.

  • 403 The key lacks search:read
    • code string required

      Stable machine-readable error code. Branch on this, never on the numeric status.

      bad_requestunauthorizedsignature_requiredpayment_requiredforbiddennot_foundconflictgonepayload_too_largeunprocessable_entitytoo_many_requestsinternal_errornot_implementedbilling_unavailablenot_contactablemailbox_link_unavailablemailbox_requiredmail_engine_unavailablewebhook_publisher_unavailabledatabase_unavailableclient_errorbuild_failed
    • message string required

      Human-readable explanation of the refusal.

    • status integer required

      The HTTP status code, repeated in the body.

    • remedy object

      A self-serve path forward, when one exists (a 402 points at how to restore access).

      • kind string required

        What kind of remedy this is, so a client can route it: whether the caller can clear the condition through the API, or a person must act in the web app.

        topupconnect_mailbox
      • url string required

        Where to go to clear the condition: an API path, or a web app page when only a person can.

  • 429 More than 30 requests a minute
    • code string required

      Stable machine-readable error code. Branch on this, never on the numeric status.

      bad_requestunauthorizedsignature_requiredpayment_requiredforbiddennot_foundconflictgonepayload_too_largeunprocessable_entitytoo_many_requestsinternal_errornot_implementedbilling_unavailablenot_contactablemailbox_link_unavailablemailbox_requiredmail_engine_unavailablewebhook_publisher_unavailabledatabase_unavailableclient_errorbuild_failed
    • message string required

      Human-readable explanation of the refusal.

    • status integer required

      The HTTP status code, repeated in the body.

    • remedy object

      A self-serve path forward, when one exists (a 402 points at how to restore access).

      • kind string required

        What kind of remedy this is, so a client can route it: whether the caller can clear the condition through the API, or a person must act in the web app.

        topupconnect_mailbox
      • url string required

        Where to go to clear the condition: an API path, or a web app page when only a person can.