OpenAI Go

openai-go is OpenAI’s officially maintained Go client, generated directly from OpenAI’s OpenAPI specification by Stainless (branded internally as Castiron). It gives Go applications typed access to the full surface of the OpenAI platform: the Responses API, the legacy-but-still-supported Chat Completions API, Realtime, Assistants (beta), Conversations, Embeddings, Fine-tuning, Batches, Vector Stores, Moderations, Files/Uploads, Images, Audio, Webhooks, and Admin endpoints.

The library leans on Go 1.24+ encoding/json omitzero semantics to distinguish “not set” from a real zero value in request params, using param.Opt[T] wrappers and generated union types (e.g. ResponseNewParamsInputUnion) instead of loosely-typed interface{} payloads. It ships first-class support for the Amazon Bedrock and Azure OpenAI-compatible endpoints, workload-identity (mTLS/X.509) authentication, and webhook signature verification via client.Webhooks.Unwrap().

Because the package lives at major version 3, its Go module path is versioned as github.com/openai/openai-go/v3 per Go modules convention; SDK v3.45.0+ requires Go 1.25, with v3.44.0 pinned as the last release supporting Go 1.22-1.24.

What You Get

• A generated Client with one service field per API resource (client.Responses, client.Chat.Completions, client.Embeddings, client.FineTuning, client.VectorStores, client.Batches, client.Admin, client.Realtime, client.Conversations, client.Webhooks, etc.)
• Type-safe request params using param.Opt[T] for optional fields and generated union types for polymorphic inputs (e.g. string vs. structured input to the Responses API)
• Built-in streaming support (client.Responses.NewStreaming, chat completion streaming) with a stream accumulator for reconstructing full responses from deltas
• Webhook signature verification (client.Webhooks.Unwrap()) that parses and authenticates OpenAI webhook payloads in one call
• Native support for Amazon Bedrock and Azure OpenAI in Azure AI Foundry as alternate backends, plus workload-identity (mTLS/X.509) authentication for enterprise deployments
• Automatic environment-variable configuration (OPENAI_API_KEY, OPENAI_ADMIN_KEY, OPENAI_ORG_ID, OPENAI_PROJECT_ID, OPENAI_WEBHOOK_SECRET, OPENAI_BASE_URL) via option.RequestOptions

Common Use Cases

• Generating text or structured JSON output from GPT models via the Responses API in a Go backend service
• Building a streaming chat interface that consumes token-by-token deltas from Responses.NewStreaming or Chat.Completions.NewStreaming
• Implementing tool/function calling where the model requests external data and the Go app resolves it and continues the conversation
• Receiving and verifying OpenAI webhook events (e.g. fine-tuning job completion) in an HTTP handler with client.Webhooks.Unwrap()
• Routing OpenAI-compatible requests through Amazon Bedrock or Azure OpenAI instead of OpenAI’s own endpoint for compliance or data-residency reasons

Under The Hood

Architecture The root Client struct in client.go composes one service field per API resource (Responses, Chat, Embeddings, FineTuning, VectorStores, Batches, Webhooks, Realtime, Conversations, Admin, and more), each backed by its own generated file or subpackage (responses/, realtime/, conversations/, webhooks/, bedrock/, azure/, auth/). Requests flow through a shared internal/requestconfig layer and an option.RequestOption pipeline that composes API key, organization, project, base URL, and retry/middleware behavior before dispatch. Backend selection (direct OpenAI, Amazon Bedrock, or Azure OpenAI in Azure AI Foundry) is handled by swapping in the bedrock or azure subpackage’s client options rather than branching application code, keeping the resource-service API identical across backends. Streaming responses are handled by a dedicated stream/accumulator layer (streamaccumulator*.go) that reconstructs a complete response object from server-sent-event deltas.

Tech Stack The module (github.com/openai/openai-go/v3, Go 1.25+) has a deliberately small direct dependency set for a client this large: github.com/tidwall/gjson/sjson for JSON path manipulation, plus Azure/azure-sdk-for-go and aws-sdk-go-v2 subpackages pulled in only for the optional Azure and Bedrock backends. Requests use Go 1.24+ encoding/json omitzero semantics via param.Opt[T] wrappers rather than a third-party validation library. CI (.github/workflows/ci.yml, codeql.yml, go-version-review.yml) runs standard go build/go test/CodeQL, plus custom detect-breaking-changes.yml and Castiron-branded code-generation checks that gate manually-edited generated code.

Code Quality The repo carries 113 _test.go files alongside their corresponding generated source files (one test per resource, e.g. chatcompletion_test.go, responses package tests, streamaccumulator_*_test.go covering lifetime, ownership, reconciliation, and logprob edge cases). Errors are returned as explicit Go error values rather than panics in library code (the README’s own examples panic() only for brevity). Naming is consistent and mechanically generated (resource+action, e.g. adminorganizationprojectuser.go), and a .golangci.yml plus documented GO_CODE_QUALITY_POLICY.md/GO_VERSION_POLICY.md formalize lint rules and the supported Go version window.

What Makes It Unique Unlike many hand-written API clients, this SDK is generated end-to-end from OpenAI’s OpenAPI spec (via the Castiron/Stainless pipeline referenced in file headers and CONTRIBUTING.md), so new API surface area ships automatically rather than through manual client updates. It also uniquely unifies three backends (OpenAI direct, Amazon Bedrock, Azure OpenAI in Azure AI Foundry) and adds enterprise-grade workload-identity (mTLS/X.509) authentication and strict webhook-signature verification with a documented 1 MiB payload-size defense-in-depth recommendation, both unusual for a generated client library.