What it does

Send a package name. Get back the numbers. 

curl -X POST https://x402.agentutility.ai/npm-package-stats \
  -d '{"package": "lodash", "recent_versions": 3}'
{
  "package": "lodash",
  "latest_version": "4.17.21",
  "total_versions": 114,
  "age_days": 4612,
  "days_since_last_release": 1180,
  "maintainer_count": 2,
  "downloads": {
    "last_day": 12100000,
    "last_week": 78200000,
    "last_month": 330000000,
    "last_year": 3970000000
  },
  "recent_versions": [
    { "version": "4.17.21", "published": "2021-02-20T15:12:43.561Z", "deprecated": false },
    { "version": "4.17.20", "published": "2020-08-13T16:34:09.450Z", "deprecated": false },
    { "version": "4.17.19", "published": "2020-07-08T01:31:01.953Z", "deprecated": false }
  ]
}

$0.003 USDC. Two upstream calls in parallel (registry + downloads), one timeout budget, one response. No LLM, no opinion — just the facts the npm registry already publishes.

Why this isn't package-risk-npm

We've had package-risk-npm for months. That endpoint costs $0.03 and runs a full supply-chain audit: install-script scanning, typosquat detection, maintainer-count weighting, deprecation flags, plus a Venice-written plain-English risk summary. It's the one to call when an agent is about to npm install something and wants a verdict.

npm-package-stats is the lower-cost surface for the case where the agent already trusts the package (it's react, lodash, axios) and just wants:

  • Is it actively maintained? (days_since_last_release)
  • How many people use it? (downloads.last_month)
  • What versions have shipped lately? (recent_versions)
  • Who's behind it? (maintainer_count, maintainers)

Different question. Different price. Both endpoints stay.

Who calls this

  • Dependency-tracking dashboards that fetch metadata for 500 packages per cron run (3 cents at our price vs 15 cents to do full risk audits)
  • README generators that want to embed a "27M weekly downloads" badge
  • LLM agents that need package context before recommending a library to a user
  • Migration assistants comparing two libraries by adoption ("React Query has 3x the weekly downloads of SWR")
  • Build tools that auto-bump deps and want to log version history

The licensing question

The npm public registry is operated by GitHub under the npm Public Registry Open Source Terms. Commercial third-party use of the registry data is explicitly permitted; the registry is "publicly available data," and operating a downstream service that wraps it is a long-running pattern (Snyk, Socket.dev, libraries.io all do this). We make the calls with a clear User-Agent header so we show up in their abuse-monitoring dashboards if anything goes sideways. No auth required.

This is the opposite of the eBay / PSA situation we hit when scoping the Comppoint cluster — npm publishes its data with the expectation that downstream tools will index it. The Open Source Terms make that explicit.

What's NOT here

  • No security vulnerability data (npm audit, GHSA) — call package-risk-npm for that
  • No source-code inspection — we don't fetch the tarball, only the registry document
  • No semver resolution beyond latest — pass an explicit version string if you need a specific one (this endpoint doesn't accept it yet; that's a follow-up)

Edge cases handled

  • Scoped packages (@types/node, @vercel/next) work — the @ is preserved through URL encoding
  • Deprecated versions get flagged in recent_versions
  • Missing fields (no homepage, no repository) return null, not undefined
  • Download-API timeouts fail soft per window (you can still get last_month: 330M, last_day: null if just the daily endpoint was slow)
  • 404 on a typo'd package name returns 404, not 502

Call it. Pairs with package-risk-npm, pypi-package-risk, and github-repo-health for a full dependency-introspection toolkit.