How to Scrape NPM Package Intelligence in 2026

The NPM registry is the largest software package index in the world, and it’s a surprisingly rich intelligence source — not just for “what version is this,” but for download trends, dependency graphs, maintainer networks, licensing, and deprecation signals. Whether you’re generating an SBOM, sizing a devtool market, or building an OSS-outreach list, the data is all there in NPM’s official, public APIs. This guide covers what’s exposed across the registry and stats endpoints, and how to export it cleanly at scale.

Why this is an API job, not a scrape

There’s no anti-bot stack to defeat here. NPM publishes everything you need through public APIs:

• The registry API — package metadata: versions, license, repository URL, maintainers, dependencies, deprecation status, the full version history.
• The downloads/stats API — usage: daily, weekly, and monthly download counts.
• Dependents data — which other packages depend on a given package.

No login, no key, no cookies, no browser, no fingerprinting. The challenge is purely breadth and stitching: a complete picture of one package requires joining several endpoints, and a complete picture of a category of packages means doing that across hundreds or thousands of them, paginating search, and normalizing the results into flat rows. That’s the work the actor does.

What’s worth extracting

Per package, stitching the registry and stats endpoints gives you:

• Identity — package name, scope (e.g., @angular/...), latest version.
• Legal — license (SPDX identifier).
• Source — repository URL (GitHub/GitLab/etc.) and homepage.
• People — maintainers.
• Usage — daily, weekly, and monthly download counts.
• Reach — dependents (packages that depend on this one).
• Health — deprecation status / message.
• Dependencies — the full dependency list (runtime, and where relevant dev/peer).
• History — version history with publish dates.

Selecting what to export: keyword, scope, maintainer, name

The actor lets you target the slice you care about instead of the whole 3-million-package registry:

• Keyword — every package matching a search term (e.g., graphql, csv parser). Great for mapping a tooling category.
• Scope — every package under an org scope (e.g., @aws-sdk). Perfect for auditing a vendor’s footprint.
• Maintainer — every package published by a given maintainer — the basis for OSS outreach and contributor analysis.
• Name — exact packages by name, for targeted SBOM or dependency lookups.

▶ Run the NPM Package Intelligence Scraper — export packages by keyword, scope, maintainer or name with downloads, deps, dependents and version history. Straight from the official NPM registry.

Schema design for downstream use

A flat per-package record that joins the registry and stats data:

{
  "name": "@acme/csv-stream",
  "scope": "@acme",
  "latest_version": "4.2.1",
  "license": "MIT",
  "repository_url": "https://github.com/acme/csv-stream",
  "homepage": "https://acme.dev/csv-stream",
  "maintainers": ["dana", "okafor-build"],
  "downloads_daily": 41250,
  "downloads_weekly": 286400,
  "downloads_monthly": 1204800,
  "dependents_count": 312,
  "deprecated": false,
  "deprecated_message": null,
  "dependencies": {
    "readable-stream": "^4.0.0",
    "csv-parse": "^5.5.0"
  },
  "version_count": 38,
  "first_published": "2019-03-04",
  "last_published": "2026-04-22",
  "scraped_at": "2026-06-01T12:00:00Z"
}

Schema choices worth making early:

• Keep all three download granularities. Daily catches spikes (a viral mention), weekly smooths weekday/weekend noise, monthly shows the trend. Each answers a different question; don’t collapse to one.
• Store dependencies as a map, not a flattened string. SBOM and dependency-graph work needs the name→range structure intact.
• Persist license as the SPDX id. License-compliance filtering (“flag anything GPL in our tree”) depends on the canonical identifier, not free text.
• Capture first_published and last_published. Together with version_count they’re your maintenance-health signal — a package with one release four years ago is a very different risk than one shipping monthly.
• Snapshot downloads over time. Like market data, the value of usage stats is the trend. Append scrapes; don’t overwrite.

Typical use cases

What devtool teams, security folks, and researchers do with this:

• Devtool market intelligence — map an entire category (every state-management lib, every test runner) by download share to size a market or position a product.
• SBOM generation — resolve a project’s dependency tree with licenses and versions into a software bill of materials for compliance/audit.
• License-compliance auditing — flag dependencies whose licenses violate your policy across a whole scope or dependency graph.
• OSS outreach & developer relations — build maintainer lists for high-traffic packages in your ecosystem for partnerships, sponsorships, or DevRel.
• Dependency-risk analysis — surface deprecated, unmaintained, or single-maintainer packages that lots of things depend on (the classic supply-chain risk).
• Competitive tracking — watch a competitor’s published packages (by scope/maintainer) for new releases, adoption, and download trends.
• Ecosystem research — study dependency-graph structure, license distribution, or release cadence across a slice of the registry.

The recurring theme is breadth + trend: one package’s stats are a curiosity, but the download trajectory of a whole category over time, or a complete dependency graph with licenses, is real intelligence.

Cost math

Pricing is pay-per-event: a tiny per-run start fee plus $0.002 per result (per package record). Because it’s pure API calls — no browser, no proxy bandwidth — runs are cheap and fast.

Example: mapping a devtool category of ~500 packages, refreshed weekly to track download trends, is ~2,000 package-records/month. At $0.002 each that’s about $4/month for a continuously-updated competitive map of your ecosystem.

You could script this yourself against the public APIs — but the fiddly parts are the search pagination, joining the registry and stats endpoints per package, handling scoped vs. unscoped names, fetching dependents, and flattening everything into consistent rows. That stitching is what the actor handles, and it’s where home-grown versions tend to drift out of sync with NPM’s API shapes.

Common pitfalls

• Download counts are noisy. CI systems, mirrors, and bots inflate raw downloads. They’re a relative popularity signal, not a precise user count — compare packages to each other, don’t read absolute headcounts into them.
• latest isn’t the whole story. A package can have a high “latest” version that’s actually a pre-release or deprecated. Always check deprecated and the version history, not just the latest tag.
• Scoped vs. unscoped names trip up filters. @org/pkg and pkg are different namespaces. Be explicit about scope when querying or you’ll over- or under-match.
• Dependents count can be large and partial. For ubiquitous packages, dependents lists are huge; treat the count as the headline and only pull the full list when you actually need the graph.
• Repository URLs are self-reported. A package can point its repository field anywhere (or nowhere). Don’t assume the URL resolves to a real, matching repo.
• One snapshot can’t show momentum. Adoption trends — the most valuable signal — require scheduled re-scrapes accumulated over time.

Wrapping up

NPM package intelligence is an open-API extraction with no bot fight — the difficulty is breadth and stitching multiple endpoints into clean, flat, trend-ready rows. For a one-off lookup of a handful of packages, the public APIs are easy enough to hit yourself. For mapping a whole category, generating an SBOM across a scope, building OSS-outreach lists, or tracking download trends over time, run it as a managed actor and let the search-pagination, endpoint-joining, and normalization be handled for you.

▶ Open the NPM Package Scraper on Apify — by keyword, scope, maintainer or name; downloads, deps, dependents, version history, deprecation. Pay per package. Start with Apify’s free monthly credit.