goldsky-go brings a dependency-free Go client to Goldsky's blockchain data APIs

A community Go client for Goldsky

Go services that consume blockchain data through Goldsky tend to accumulate the same HTTP plumbing: authorization headers, retry decisions, pagination tokens and JSON-RPC envelope checks. A new community SDK called goldsky-go, introduced in a post on dev.to, folds that integration work into a single idiomatic Go client so teams can spend their attention on product logic instead.

The library is independently maintained rather than being an official Goldsky package, and it lives at github.com/tigusigalpa/goldsky-go. According to the announcement, it targets version 1.2.0 of the Goldsky REST API and maps all 40 documented REST operations, while also providing first-class access to Subgraph GraphQL endpoints and Goldsky Edge HTTPS JSON-RPC. That puts control-plane work — managing pipelines, subgraphs, webhooks and Edge endpoints — and data-plane work, such as querying indexed data or calling an RPC endpoint, behind one client model.

Standard library only

One of the more distinctive choices is that goldsky-go has no third-party runtime dependencies. It is built on the Go standard library rather than a large HTTP abstraction stack, which the dev.to post frames as a practical advantage for services where dependency surface area and deployment simplicity matter.

Public methods accept context.Context, and the stable API shapes use typed request and response models. The constructor validates options without making a network call, which keeps application startup and tests predictable. The intended pattern is to create a client once with a project API token and an application-appropriate timeout, then reuse it, giving each individual operation its own deadline through the context. Installation requires Go 1.22 or later.

One client, seven services

Instead of asking callers to assemble endpoint URLs by hand, the SDK organizes functionality into services:

• Pipelines: validate, create, inspect, pause, resume, restart, delete and observe Turbo Pipelines
• Subgraphs: deploy bundles, manage versions and tags, read indexing logs and webhook entities
• Webhooks: create, list and delete entity webhooks
• Edge: manage endpoints, keys, lifecycle actions and metrics
• Catalogs: discover available subgraph chains, Edge networks and Edge Data sources
• GraphQL: send public or private Subgraph GraphQL queries
• RPC: make individual or batch JSON-RPC 2.0 calls through Goldsky Edge

A complete method-to-operation mapping is maintained in the repository's API coverage document.

Pagination and deploys

Pagination is handled with pager objects that follow Goldsky's continuation-token scheme rather than inferring the end of a result set from page sizes — a short page is not necessarily the last page. Pagers for pipelines, subgraphs and Edge endpoints keep requesting until no next-page token comes back, reject invalid sizes locally, and return an empty page after the final one instead of firing needless HTTP requests. The post notes that pagers are not intended for concurrent use, although the reusable client and its services are safe to share.

Subgraph deployment streams a zip bundle as multipart/form-data instead of buffering the whole archive in application memory. Deployments are deliberately not retried automatically: an arbitrary io.Reader cannot necessarily be replayed, and an ambiguous timeout on a mutation could otherwise produce duplicate or confusing outcomes. The recommended pattern is to check whether the first attempt took effect, reopen the file, and only then retry.

Schemas stay with the application

For GraphQL, the SDK returns query results as .RawMessage alongside errors, headers and the HTTP status, and leaves decoding to the caller. Because different subgraphs expose different entities and fields, generating universal types would be brittle; each application decodes the structure it expects, keeping the client honest about the fact that Web3 data has no single static schema.

Why it matters

Goldsky sits in a growing stack of blockchain indexing infrastructure, and Go is a common choice for the services built on top of it. Teams integrating with Goldsky previously had to hand-roll HTTP details or accept a heavier dependency to reach its APIs. goldsky-go offers a middle path: typed, context-aware methods across the full documented surface, zero runtime dependencies, and explicit operational rules in exactly the places where silent convenience is dangerous — retrying deployments, guessing at pagination, or pretending all subgraph data shares one schema. As a community project, its long-term coverage depends on its maintainer, but it substantially lowers the cost of bringing Goldsky data into Go services.