Back to checker

Why I built BundleCheck

I needed bundle sizes for a side project. A simple API: give it a package name, get back raw, minified, gzip, and brotli sizes.

That should have been straightforward. It wasn't.

What I found in existing options

  • Slow: 5-10 second responses are fine for one-off browser checks, but too slow for CI and integrations.
  • Broken: docs with 404s, unstable endpoints, and UI/API behavior mismatches.
  • Paywalled too early: useful APIs that block basic testing after a few requests.

So I built the API I wanted

BundleCheck is developer-first: one endpoint, explicit errors, and cache-aware responses so you can tell whether the result was fresh or cached.

Endpoint: GET /v1/api/size?package=<name>&version=<optional> with X-API-Key.

curl -H "X-API-Key: $BUNDLECHECK_API_KEY" \
  "https://bundlecheck.dev/v1/api/size?package=react&version=latest"

If you are building for developers

The API is built for dependency dashboards, internal tooling, and anywhere you need bundle size data without UI friction. For CI today, a curl step is enough:

- name: Check bundle size
  run: |
    curl -sf -H "X-API-Key: $BUNDLECHECK_API_KEY" \
      "https://bundlecheck.dev/v1/api/size?package=your-package&version=latest"

What's next

  • GitHub Action — drop-in CI integration with PR comments, size diffs, and threshold enforcement. No curl required.
  • Version comparison — check how bundle size changed between two versions of the same package.
  • Batch endpoint — check multiple packages in a single request, useful for dependency audits.

If any of these would unblock a use case for you, mention it when you — it directly shapes the order things ship.

Request beta API access

Beta is open for teams and solo builders. Share your use case and expected volume, and I'll prioritize onboarding and limits based on real needs.