InfluxDB Client Go

influxdb-client-go is InfluxData’s official Go client library for InfluxDB 2.x, giving Go programs a typed interface over InfluxDB’s HTTP API instead of hand-rolled REST calls. It covers the two things most integrations need first — writing line-protocol/point data and running Flux queries — through both an asynchronous, batched WriteAPI and a synchronous WriteAPIBlocking, plus a QueryAPI that streams Flux table results back as iterable records.

Beyond the write/query path, the client wraps the full InfluxDB 2 management surface: server setup and onboarding, health/ready/ping checks, and dedicated API objects for authorizations, organizations, users, buckets, labels, tasks, and delete predicates. Request/response types for these endpoints are generated from InfluxDB’s OpenAPI spec via oapi-codegen, so the client’s domain models track the server API directly rather than being maintained by hand. It also carries a compatibility shim for talking to InfluxDB 1.8 servers, useful for teams migrating between major versions.

What You Get

• A Client interface exposing WriteAPI/WriteAPIBlocking for async or synchronous writes, and QueryAPI for Flux queries
• Point construction helpers (NewPoint, fluent NewPointWithMeasurement) alongside raw line-protocol write support
• Management API clients for authorizations, organizations, users, buckets, labels, tasks, and delete predicates
• Server lifecycle calls: Setup/SetupWithToken for onboarding, plus Ready, Health, and Ping
• OpenAPI-generated domain types (domain package) kept in sync with InfluxDB’s server-side API spec
• An InfluxDB 1.8 compatibility shim (compatibility.go) for incremental migration off the v1 client

Common Use Cases

• Ingesting sensor/IoT telemetry into InfluxDB as line-protocol points from a Go service
• Running Flux queries against a bucket and iterating results row-by-row in application code
• Provisioning a fresh InfluxDB instance (users, org, bucket, retention) as part of a deployment script
• Building internal tooling that manages buckets, tasks, or authorizations programmatically instead of via the UI
• Bridging an application still targeting InfluxDB 1.8 while planning a move to InfluxDB 2.x

Under The Hood

Architecture The module splits into three layers: client.go defines the top-level Client interface (clientImpl in practice) that lazily hands out per-org/bucket API objects — WriteAPI, WriteAPIBlocking, QueryAPI, and the management clients (AuthorizationsAPI, OrganizationsAPI, UsersAPI, BucketsAPI, LabelsAPI, TasksAPI, DeleteAPI) — each implemented under api/. Those in turn delegate to internal/ packages (internal/write, internal/http, internal/gzip, internal/log) that own connection pooling, batching, and gzip-compressed transport, keeping transport concerns out of the public surface. A third layer, domain/, holds request/response types and an API client generated from InfluxDB’s OpenAPI spec via oapi-codegen, so protocol changes on the server side propagate through code generation rather than manual edits. Losing the domain generation step would require hand-maintaining every InfluxDB endpoint’s request/response shape.

Tech Stack Written in Go 1.25, with github.com/oapi-codegen/runtime backing the generated domain client, github.com/influxdata/line-protocol for encoding points, and golang.org/x/net for HTTP transport internals. github.com/google/uuid and github.com/apapsch/go-jsonmerge/v2 are minor supporting dependencies pulled in transitively by the generated domain layer. No ORM or database driver is involved — this is purely an HTTP client wrapping InfluxDB’s REST/Flux endpoints; build and release automation runs through a Makefile (lint, make server against a local InfluxDB instance, coverage) rather than bare go build.

Code Quality Testing is extensive and split by intent: unit tests alongside the source they cover (client_test.go, options_test.go, api/write/point_test.go, api/query/table_test.go) using stretchr/testify for assertions, plus separate *_e2e_test.go files (buckets_e2e_test.go, authorizations_e2e_test.go, tasks_e2e_test.go, etc.) that exercise the client against a live InfluxDB server started via make server in CI. CircleCI runs make lint before tests and uploads coverage to Codecov. Errors are returned as typed Go error values throughout the public API rather than panicking or swallowing failures, and the public Client interface plus generated domain types give callers compile-time type safety over API responses.

What Makes It Unique The standout choice is generating the management-API surface (buckets, orgs, users, tasks, authorizations) directly from InfluxDB’s own OpenAPI specification via oapi-codegen, rather than committing to hand-written wrapper structs that drift from the server. Combined with offering both an async, internally-batched WriteAPI and a synchronous WriteAPIBlocking from the same client — plus a dedicated compatibility path for InfluxDB 1.8 — it covers both the common ingestion path and the long tail of admin operations that most community-maintained clients skip.