devLap

pkg.go.dev Finally Has an Official API — No More Web Scraping

go dev.to

If you've ever built a Go tool that needed package metadata — documentation, versions, symbols, import counts — you already know the pain. You were either scraping the pkg.go.dev HTML (fragile, bad, and you knew it), or you were guessing from local filesystem data and hoping for the best.

The Go team just shipped a real fix for this: an official pkg.go.dev API.

Let's look at what it actually does.

What's Available

The API lives under /v1beta and covers the main things you'd actually need:

Endpoint What it gives you
/v1beta/package/{path} Package metadata
/v1beta/module/{path} Module metadata
/v1beta/versions/{path} All versions of a module
/v1beta/packages/{path} All packages in a module
/v1beta/search?q={query} Search results
/v1beta/symbols/{path} Exported symbols
/v1beta/imported-by/{path} What imports this package
/v1beta/vulns/{path} Known vulnerabilities

The v1beta label is honest — it's not finalized yet. But the team has committed to moving toward a stable v1 after a feedback period, and they're promising backward compatibility going forward.

Quick Start: Hit It With curl

No auth, no setup. Just GET requests:

curl https://pkg.go.dev/v1beta/package/github.com/google/go-cmp/cmp | jq .
Enter fullscreen mode Exit fullscreen mode

Response:

{"modulePath":"github.com/google/go-cmp","version":"v0.7.0","isLatest":true,"isStandardLibrary":false,"goos":"all","goarch":"all","path":"github.com/google/go-cmp/cmp","name":"cmp","synopsis":"Package cmp determines equality of values.","isRedistributable":true}
Enter fullscreen mode Exit fullscreen mode

You can pin a specific version:

curl "https://pkg.go.dev/v1beta/package/github.com/google/go-cmp/cmp?version=v0.6.0" | jq .
Enter fullscreen mode Exit fullscreen mode

Or use master / main branch names, which resolve automatically to their pseudo-version:

curl -s "https://pkg.go.dev/v1beta/package/github.com/google/go-cmp/cmp?version=master" | jq '{path, version}'
# {
#   "path": "github.com/google/go-cmp/cmp",
#   "version": "v0.7.1-0.20260310220054-34c9473539b8"
# }
Enter fullscreen mode Exit fullscreen mode

One Gotcha: Module Paths Must Be Unambiguous

This tripped me up when I first read the docs. The API follows a "precision over convenience" rule that differs from the web UI.

On the website, if you type example.com/a/b/c, it resolves to the longest matching module path automatically. The API won't do that. If example.com/a/b/c could live in either example.com/a or example.com/a/b, the API returns an error and asks you to be more specific.

Makes sense for programmatic use — you don't want silent resolution surprises in a tool. Just something to plan for when you're building integrations.

The Reference CLI: pkgsite-cli

The Go team also shipped a reference client you can install and start using immediately:

go install golang.org/x/pkgsite/cmd/internal/pkgsite-cli@latest
Enter fullscreen mode Exit fullscreen mode

Search for packages:

pkgsite-cli search "uuid"
# github.com/google/uuid
#   Module:   github.com/google/uuid@v1.6.0
#   Synopsis: Package uuid generates and inspects UUIDs.
Enter fullscreen mode Exit fullscreen mode

Inspect a package:

pkgsite-cli package github.com/google/go-cmp/cmp
Enter fullscreen mode Exit fullscreen mode

See what imports a package:

pkgsite-cli package --imported-by github.com/google/go-cmp/cmp
Enter fullscreen mode Exit fullscreen mode

List exported symbols:

pkgsite-cli package --symbols github.com/google/go-cmp/cmp
Enter fullscreen mode Exit fullscreen mode

List all versions of a module:

pkgsite-cli module -versions github.com/google/go-cmp
Enter fullscreen mode Exit fullscreen mode

Worth noting: the CLI interface is explicitly marked as unstable — it's a reference implementation, not a finished product. Use it to understand the API, not as a dependency in scripts you care about.

Why This Matters Now

The "years of community feedback" line in the announcement is underselling it. Go tooling has had a real data access gap for a long time. Custom linters, documentation generators, dependency analyzers, IDE plugins — all of them were either scraping or going without.

The announcement also mentions AI-assisted coding tools specifically, and that's probably the real driver here. Tools that reason about your dependencies need structured, reliable data about packages. Scraping doesn't cut it when you want a language server to tell you something accurate about a module it's never seen before.

An OpenAPI spec is published too, so generating clients in any language is straightforward.

What I'd Use This For

A few things come to mind immediately:

Dependency audits — pull vulnerability data via /v1beta/vulns/{path} for every module in your go.sum without spinning up a full govulncheck run.

Import graph tooling — the /v1beta/imported-by endpoint makes it practical to build tools that understand downstream impact of an API change.

Documentation bots — fetch synopsis and symbol data for packages your team uses, feed it wherever you need it.

Version tracking — watch specific modules for new releases without polling GitHub.

The State of It

It's a v1beta. The endpoints work, the data is good, and the team is clearly committed to making this a real stable API. But I wouldn't bet a production pipeline on the exact response shape staying identical until v1 lands.

For internal tooling and experiments? Use it today. For anything you're shipping to other people? Keep an eye on the issue tracker and wait for v1.

Go give it a curl. The full API spec and OpenAPI definition are live now.

Feedback and bug reports go to the pkgsite issue tracker. The team specifically asked for community feedback before the v1 freeze, so this is a good time to poke at edge cases.

Source: dev.to

arrow_back Back to Tutorials