Introducing the pkg.go.dev API - The Go Programming Language

The Go Blog

Introducing the pkg.go.dev API

Ethan Lee, Hana Kim, and Jonathan Amsterdam

21 May 2026

Since its inception, pkg.go.dev has established itself as<br>the Go community&rsquo;s primary resource for package documentation and discovery.<br>While we initially prioritized creating a comprehensive and highly accessible<br>web interface for users, the need for programmatic access has become<br>increasingly clear. Developers building tools, IDE integrations, and automated<br>workflows have historically relied on fragile workarounds like web scraping to<br>access this data. To better address these evolving requirements, we are now<br>expanding our platform to provide robust, direct access to the information our<br>community needs.

Today, we are excited to introduce the official<br>pkg.go.dev API — a service interface for querying<br>metadata about published Go modules. This launch is a direct response to<br>years of community feedback. Furthermore, the need for a formalized<br>interface has become even more acute with the rise of AI-assisted coding.<br>Tools can now access the specific, high-fidelity context needed to reason<br>about the Go ecosystem with greater precision.

The service interface

Built for stability and efficient caching, the API uses a stateless, GET-only<br>architecture. Primary endpoints are currently hosted under the /v1beta path.<br>Following a period of community feedback and confirmed stability, we intend to<br>transition toward a formal v1 release.

For a complete interactive reference of all endpoints, query parameters, and<br>response shapes, see the pkg.go.dev/api specification.<br>The machine-readable API contract is also published directly as an OpenAPI<br>specification.

Core endpoints

Endpoint<br>Description

/v1beta/package/{path}<br>Information about the package at {path}.

/v1beta/module/{path}<br>Information about the module at {path}.

/v1beta/versions/{path}<br>Versions of the module at {path}.

/v1beta/packages/{path}<br>Information about packages of the module at {path}.

/v1beta/search?q={query}<br>Search results for a given query.

/v1beta/symbols/{path}<br>List of symbols declared by the package at {path}.

/v1beta/imported-by/{path}<br>Paths of packages importing the package at {path}.

/v1beta/vulns/{path}<br>Vulnerabilities of the module or package at {path}.

One design principle for this API is &ldquo;precision over convenience.&rdquo; For context,<br>when go mod tidy encounters an import of a package that isn&rsquo;t provided by an<br>existing dependency of the main module, it applies the &ldquo;longest module path&rdquo;<br>rule to determine which module is needed. (The fact that two or more modules<br>could provide the package is what makes it possible to later carve out a<br>submodule without breaking existing programs.) The<br>pkg.go.dev web interface follows a similar convention<br>when choosing which package to display for a given package path.<br>By contrast, the pkg.go.dev API requires the module to be<br>specified unambiguously. If a package path is ambiguous because it exists in<br>multiple modules, the API returns a list of candidates and reports an error<br>asking the client to be more specific.

For example, a package imported as example.com/a/b/c could be provided by<br>module example.com/a or by example.com/a/b. While the<br>pkg.go.dev web interface will automatically resolve the<br>&ldquo;longest module path&rdquo; (example.com/a/b), a client querying the API must<br>specify the module explicitly to avoid an ambiguous resolution error.

Specifying versions

For endpoints that retrieve package, module, or symbol information, you can<br>specify the desired version using the optional version query parameter. The<br>API returns information about the latest version of the module or package by<br>default. The parameter supports:

Semantic Versions: Retrieve data for a specific release tag (e.g.,<br>?version=v1.2.3 or ?version=v0.6.0).

Branch Names: Reference default development branches—specifically master<br>or main (e.g., ?version=master). The API will automatically resolve the<br>branch to its corresponding pseudo-version. Note that custom or arbitrary<br>branch names are not supported.

If the version parameter is omitted, the API defaults to resolving the<br>request against the latest tagged version of the package or module.

Example: raw API request

To retrieve structured metadata for a specific package directly (using jq for<br>formatting):

$ curl https://pkg.go.dev/v1beta/package/github.com/google/go-cmp/cmp | jq .<br>"modulePath": "github.com/google/go-cmp",<br>"version": "v0.7.0",<br>"isLatest": true,<br>"isStandardLibrary": false,<br>"goos": "all",<br>"goarch": "all",<br>"path": "github.com/google/go-cmp/cmp",<br>"name": "cmp",<br>"synopsis": "Package cmp determines equality of values.",<br>"isRedistributable": true

To query a specific branch version (like master) and see it resolve<br>automatically to its corresponding pseudo-version:

$ curl -s "https://pkg.go.dev/v1beta/package/github.com/google/go-cmp/cmp?version=master" | jq '{path,...