GitHub REST API (Repositories & Search)

Datadory delivers github rest api repositories search data covering the public GitHub repository corpus: over 200 million repositories, each a flat record of twenty documented fields spanning stars, forks, open issues, primary language, maintainer topics, detected license and three lifecycle timestamps. Filtered by language, topic, popularity or project age, it becomes a delivered feed - daily, weekly, or hourly.

The public side of GitHub is the largest collection of open-source application software in the world, and every bit of it is described by a machine-readable record: one flat JSON object per repository, more than 200 million of them. Each object bundles identity (numeric id, owner login, full name, maintainer-written description), popularity (stargazer, watcher and fork counts, open issue volume), classification (primary language as detected by GitHub's Linguist engine, lowercase maintainer-applied topics, a detected license, a declared homepage) and lifecycle (creation, update and last-push timestamps, an archived flag, visibility level).

Datadory turns that catalog into a delivered feed - filtered, shaped and shipped the way your pipeline wants it. If you size markets by counting repositories, score competitors by their stars-versus-issues posture, or screen dependencies before adoption, this is the base layer under all of it. Get a sample of this dataset and the dictionary below stops being hypothetical.

What does a sample row look like?

One captured record beats a paragraph of specification. Here is a real one - the top result when the catalog is queried for the application-software topic:

full_name   : rjlovespy/Mindnote
id          : 670418243
node_id     : R_kgDOJ_XFQw
description : An application software that is an advanced version of notepad
fork        : false

Yes - asked for application software, the corpus opens with an advanced version of notepad. That is the honest texture of the thing: hundreds of millions of repositories, most of them small, a few of them destined to run half the internet, all wearing the same twenty-field shape. The volume is exactly why the counters matter. Stars, forks and issue counts are how signal climbs out of it.

What fields does the dataset include?

Twenty documented fields, definitions verified against live responses during cataloging. The dictionary below is the complete core schema: every repository record carries all twenty, and none of them require a secondary lookup to interpret.

What does coverage look like across geography, time and granularity?

Geography — global. The corpus is every public repository hosted on GitHub, in every country and every human language. Geography arrives implicitly, through maintainer names and descriptions, rather than as a dedicated column.

Temporal — every record self-describes its own history with three timestamps: created_at (project birth), updated_at (last metadata change) and pushed_at (most recent code push). Cohort any slice by creation month or filter by last-push recency and the timeline reconstructs itself, no external calendar table required.

Granularity — one flat record per repository, delivered in batches of up to 100 records. Nothing nested to unwind; roll up to owner or organization level yourself if the analysis calls for it.

How is the data delivered?

API, files, or your warehouse. Daily, weekly, or hourly.

Who uses this data, and for what?

  • Technology-landscape sizing — count repositories by primary language and topic to measure where a category is thick or thin before committing a roadmap to it.
  • Competitor open-source tracking — stars, forks and open-issue counts turn rivals' public projects into a readable activity curve.
  • Dependency due diligence — the archived flag, fork status, detected license and last-push timestamp screen a candidate library's health in one glance.
  • Developer-tool market maps — maintainer-applied topics cluster the corpus into de facto categories and reveal the vocabulary a niche already uses for itself.
  • Model training corpora — a stable twenty-field schema over hundreds of millions of behavior-labeled objects is ready-made input for ranking and recommendation systems.

Which personas get the most value?

Competitive intelligence and product teams read rivals' public repositories as a leading indicator - issue velocity and fork counts tend to move before launch announcements do. Data scientists and ML engineers get a clean, schema-stable corpus large enough to train on without augmentation. Developers and data-product builders wrap the flat record shape into dependency checkers and ecosystem dashboards without schema gymnastics. Investors and quant researchers use language- and topic-level repository growth as a bottom-up gauge of developer mindshare.

What should I know before requesting a sample?

Three things worth knowing upfront. First, the headline corpus size - more than 200 million repositories - is a widely cited order of magnitude rather than a frozen inventory figure; the live total moves constantly and is reported precisely with every query result. Second, eleven of the twenty fields (the timestamps, counters and flags) ship without a single representative example value because they vary by orders of magnitude across repositories; request a sample and they populate immediately. Third, popularity metrics measure attention, not quality - a modestly starred library with recent pushes routinely beats a famous one whose archived flag flipped years ago.

Which datasets sit next to this one?

Application Software catalog neighbors that answer different halves of the software-market question. Libraries.io Open Source Packages extends the open-source view into package-manager dependency graphs. G2 Software Categories & Product Pages and Capterra Software Directory cover the commercial, review-driven side of the market. Product Hunt - New Software Launches catches products on day one, before any counters accumulate.

Field dictionary

Every field below is documented against real records. The full dictionary ships with the sample.

Field dictionary - twenty documented fields, one flat record per repository
fieldtypedefinitionexample
idintegerNumeric GitHub repository identifier.670418243
node_idstringGraphQL global node identifier for the repository.R_kgDOJ_XFQw
full_namestringOwner login and repository name joined by a slash.rjlovespy/Mindnote
descriptiontextRepository description supplied by the maintainer.An application software that is an advanced version of notepad
forkbooleanWhether the repository was created as a fork of another.false
created_atdatetimeTimestamp when the repository was created.
updated_atdatetimeTimestamp of the last metadata update to the repository record.
pushed_atdatetimeTimestamp of the most recent git push to any branch.
homepagestringProject website URL declared by the maintainers.
sizeintegerRepository working-tree size in kilobytes.
stargazers_countintegerNumber of users who have starred the repository.
watchers_countintegerNumber of users watching the repository.
forks_countintegerNumber of forks of the repository.
open_issues_countintegerCount of open issues and pull requests.
languagestringPrimary programming language detected by GitHub Linguist.Python
topicstextLowercase topical labels applied by maintainers, saved as lowercase.
licenseenumDetected license object with key, name, spdx_id and url fields.{"key": "other", "name": "Other", "spdx_id": "NOASSERTION"}
default_branchstringName of the default branch.main
archivedbooleanWhether the repository has been archived and made read-only.
visibilityenumRepository visibility level.public

Questions buyers ask

How many repositories does the data cover?

More than 200 million public repositories are indexed and searchable, spanning every programming language and topic on GitHub. That figure is a widely cited order of magnitude rather than a frozen count - the live total moves continuously and is reported exactly with each query result, so sizing queries always return current numbers.

How far back does repository history go?

Every record carries created_at, updated_at and pushed_at, and the corpus reaches from GitHub's first public repositories to the present. Because birthdates ride on the records themselves, cohort analysis by creation month works across the whole history without stitching together external archives.

What can I segment the corpus by?

Primary programming language, maintainer-applied topics, star and fork counts, open-issue volume, detected license, archive and fork status, and creation window. Combinations compose freely - say, TypeScript repositories carrying a given topic, created after a cutoff date, past a thousand stars.

How can I tell active projects from abandoned ones?

Three fields do most of the work: pushed_at shows the last code push, the archived boolean marks repositories their maintainers have made read-only, and open_issues_count shows whether anyone still files and triages problems. A recent push with a rising issue count is the signature of a living project.

Is the schema stable enough for production pipelines?

Yes. Twenty fields are documented once and appear identically on every repository record, verified against live responses during cataloging. Pipelines written against the dictionary run unchanged whether they process a hundred records or millions, and extended keys beyond the core twenty can be specified when you request a sample.

See the rows before you pay anything.

Name this dataset and we send real records from it — scoped to the fields you asked for.

See pricing