npm Public Registry API

Every JavaScript project in the world starts by resolving against this one database. The npm Public Registry is the authoritative store of JavaScript and Node.js packages, and at the August 2026 cataloging pass it held roughly 4.3 million package documents, each a typed record rather than a web page: every published version with its own manifest, dependency maps, engines and integrity hashes; distribution tags marking the channel installers resolve; maintainers, license declarations, repository links; and publication timestamps that reach back to the registry's 2010 inception. npm Public Registry API is that corpus as a delivered feed - 28 documented fields spanning the metadata, download-count and search surfaces.

Two properties make it pipeline material rather than a lookup tab. First, popularity is measured, not asserted: download counters run per package per day from 2015-01-10 onward, so adoption claims become arithmetic - express alone recorded 109,311,848 downloads in the week ending 19 August 2026. Second, the structure survives contact with scale: the same twenty-eight fields describe a two-maintainer utility and a framework half the internet installs, which is why joins behave. Get a sample of this dataset and real rows arrive before anything recurring.

Three surfaces, one capture - transposed for reading:

# weekly download point count - express
package    : express
downloads  : 109311848        # 2026-08-13 .. 2026-08-19

# search hit - express, scored
version         : 5.1.0
description     : Fast, unopinionated, minimalist web framework
quality         : 1.0   | popularity : 1.0   | maintenance : 1.0
keywords        : express, framework, sinatra, rest, restful, router, app, microservices

# one version manifest - express 4.19.2
dependencies    : accepts ~1.3.8, body-parser 1.20.2, debug 2.6.9
engines.node    : >= 0.10.0
fileCount       : 73          unpackedSize: 217566

Read what the trio proves. The download line is a weekly total for one package - a number that turns 'everyone uses Express' into a figure you can chart, diff and cite. The search block is the registry grading its own homework: express scores a perfect 1.0 on quality, popularity and maintenance simultaneously, and the keyword list shows how packages classify themselves. And the version manifest carries the supply-chain facts - exact dependency pins like accepts ~1.3.8, a node engine floor, seventy-three files unpacking to about 212 KB - that let you screen a candidate without installing it. Three captured records from the August 2026 verification pass - the weekly download total for express, its scored search hit, and one version manifest flattened for reading. Values are quoted exactly as observed (the weekly figure covers 13-19 August 2026); your sample re-cuts all three surfaces to the packages you name. Request your sample and all three surfaces arrive shaped to your package list.

Twenty-eight documented fields span the three surfaces the registry serves: twenty-one describe each package and its versions - identity, lifecycle stamps, maintainership, licensing, dependency maps, integrity hashes and sizes - while the remaining seven carry the measurement layer of download totals, window dates, search results and scoring detail. Definitions were verified against live responses during the August 2026 cataloging pass, which is why this record scores 10 out of 10 on our field-documentation rubric against a catalog average of 7.81 across 1,744 datasets.

Additional fields on request: the abbreviated install-metadata view that strips documents down to what installers need, per-version breakdowns of download counts beyond the trailing week, bulk multi-package count pulls at up to 128 names per query, the change-feed sequence position used to keep a synchronized copy current, and derived columns such as maintainer normalization, category rollups and download percentile bands. Name the packages and windows when you request a sample and the extract arrives carrying exactly those columns.

Geography - global by construction. One namespace holds the entire JavaScript ecosystem regardless of where its maintainers sit, and download counts aggregate worldwide installs. Geography arrives implicitly through maintainer names and repository links rather than as a partition; anything geographic worth building is derived downstream.

Temporal - two clocks worth telling apart. Metadata is current registry state with publication timestamps per version, so the decade-and-a-half arc of the ecosystem reconstructs straight from the records - packages from the 2010-era registry still resolve. Download counts run on their own clock: daily values from 2015-01-10 through yesterday, with per-version breakdowns limited to the trailing week.

Granularity - per package, per version and per maintainer in the metadata; per package per day in the counts. Of the ~4.3 million documents, roughly 2.5-3 million carry download records at all - the rest have never been installed, which is itself a signal. Roll-ups to keyword, category or maintainer level are group-bys, not integration projects.

Against the wider catalog - average quality score 7.81 across 1,744 datasets - this slice holds 10/10, carried by fully exampled field documentation verified against live responses.

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

The registry is enormous and unevenly interesting, which makes shaping the first decision: whole-ecosystem copies suit teams running supply-chain screens or market maps in SQL; single-package and category extracts suit products that surface a library's health mid-workflow; download series suit analysts charting adoption. Deliveries key on package name and version, so consecutive pulls diff cleanly into release-churn and adoption timelines instead of re-downloading history, and the dictionary above travels unchanged across all three channels.

• Dependency due diligence and supply-chain screening - screen candidate libraries on maintainer records, publish recency, license declarations and integrity hashes before anything enters a lockfile.
• Adoption and market-share analytics - daily download series turn 'which framework is winning' into an arithmetic question, cohortable by month and segmentable by keyword.
• Competitive intelligence on developer ecosystems - watch rivals' packages across deliveries; version churn and download acceleration tend to move ahead of press releases.
• License-compliance sweeps - SPDX identifiers on every package make copyleft exposure a filter over rows rather than a manual audit.
• Ecosystem mapping and model training - keywords, categories and dependency edges give ranking and recommendation systems a labeled corpus measured in millions.

See the market sizing playbook and competitor tracking use cases for the workflows this feeds.

Developers and data-product builders hold this dataset at the top tier - registry-backed dashboards, update watchers and install-time policy gates all read off one documented schema (developers builders use cases). Data scientists and ML engineers get a corpus large enough to train on with labels already attached: licenses, scores and dependency edges (data scientists use cases). Competitive-intel and product teams read rivals' publishing cadence as a leading indicator (competitive intel product teams use cases). Investors and quants track download trajectories as bottom-up evidence of developer mindshare (investors quants use cases), and journalists and academics cite measured adoption curves rather than anecdotes.

Three things worth settling upfront. First, scale versus focus: the full corpus is millions of documents, so decide whether the sample answers a whole-ecosystem question or resolves a named package list - both work, but they shape differently. Second, the measurement layer has edges: download counts begin on 2015-01-10 and stop at yesterday, roughly a quarter of packages carry no download record at all because they were never installed, and per-version breakdowns reach only the trailing seven days. Third, absence is informative here - an unpublished or never-installed package looks like a zero, not an error, so pipelines should treat missing counts as a state rather than a fault. Name your packages, keywords and windows when you request and the sample comes back pre-cut.

Within Systems Software this record owns JavaScript at registry depth. crates.io - Rust Package Registry API runs the same job for Rust - around 320,000 crates with billions of cumulative downloads - and PyPI - Python Package Index API and Stats covers Python with 877,215 projects; both are the natural companions for cross-language adoption studies. deps.dev - Open Source Insights API reads npm alongside six other registries and adds pre-resolved graphs, advisories and Scorecard health, but normalizes away some registry-native detail - the head-to-head comparison sets out the trade. Libraries.io Open Source Packages spans 32 package managers breadth-first with a frozen graph. When the question is end-of-life windows rather than packages, endoflife.date Product Lifecycle Catalog covers products, not libraries - the npm-side comparison draws that boundary precisely.

Notes that travel with this dataset:

• Systems software data hub - the pooled industry view, from package registries to OS share and developer surveys.
• vs deps.dev - raw registry depth against cross-ecosystem resolution, the slice's sharpest contrast.
• Persona pages - what developers, quants and data scientists each do with registry-scale records.