ogen

OpenAPI v3 Code Generator for Go.

• Getting started
• Sample project
• Security policy
• Telegram group @ogen_dev

Install

go install -v github.com/ogen-go/ogen/cmd/ogen@latest

Usage

//go:generate go run github.com/ogen-go/ogen/cmd/ogen --target target/dir -package api --clean schema.json

or using container:

docker run --rm \
  --volume ".:/workspace" \
  ghcr.io/ogen-go/ogen:latest --target workspace/petstore --clean workspace/petstore.yml

Features

• No reflection or interface{}
  • The json encoding is code-generated, optimized and uses go-faster/jx for speed and overcoming encoding/json limitations
  • Validation is code-generated according to spec
• Code-generated static radix router
• No more boilerplate
  • Structures are generated from OpenAPI v3 specification
  • Arguments, headers, url queries are parsed according to specification into structures
  • String formats like uuid, date, date-time, uri are represented by go types directly
• Statically typed client and server
• Convenient support for optional, nullable and optional nullable fields
  • No more pointers
  • Generated Optional[T], Nullable[T] or OptionalNullable[T] wrappers with helpers
  • Special case for array handling with nil semantics relevant to specification
    • When array is optional, nil denotes absence of value
    • When nullable, nil denotes that value is nil
    • When required, nil currently the same as [], but is actually invalid
    • If both nullable and required, wrapper will be generated (TODO)
• Support for untyped parameters (any)
  • Parameters with no type specified in schema are represented as Go any
  • Decoded as strings from URI (path, query, header, cookie)
  • Client encoding uses fmt.Sprint for flexible value conversion
  • Useful for legacy APIs or dynamic parameter types
• Generated sum types for oneOf
  • Primitive types (string, number) are detected by type
  • Discriminator field is used if defined in schema
  • Type is inferred by unique fields if possible
    • Field name discrimination: variants with different field names
    • Field type discrimination: variants with same field names but different types (e.g., {id: string} vs {id: integer})
    • Field value discrimination: variants with same field names and types but different enum values
• Extra Go struct field tags in the generated types
• OpenTelemetry tracing and metrics
• Server-Sent Events (SSE) support

Example generated structure from schema:

// Pet describes #/components/schemas/Pet.
type Pet struct {
	Birthday     time.Time     `json:"birthday"`
	Friends      []Pet         `json:"friends"`
	ID           int64         `json:"id"`
	IP           net.IP        `json:"ip"`
	IPV4         net.IP        `json:"ip_v4"`
	IPV6         net.IP        `json:"ip_v6"`
	Kind         PetKind       `json:"kind"`
	Name         string        `json:"name"`
	Next         OptData       `json:"next"`
	Nickname     NilString     `json:"nickname"`
	NullStr      OptNilString  `json:"nullStr"`
	Rate         time.Duration `json:"rate"`
	Tag          OptUUID       `json:"tag"`
	TestArray1   [][]string    `json:"testArray1"`
	TestDate     OptTime       `json:"testDate"`
	TestDateTime OptTime       `json:"testDateTime"`
	TestDuration OptDuration   `json:"testDuration"`
	TestFloat1   OptFloat64    `json:"testFloat1"`
	TestInteger1 OptInt        `json:"testInteger1"`
	TestTime     OptTime       `json:"testTime"`
	Type         OptPetType    `json:"type"`
	URI          url.URL       `json:"uri"`
	UniqueID     uuid.UUID     `json:"unique_id"`
}

Example generated server interface:

// Server handles operations described by OpenAPI v3 specification.
type Server interface {
	PetGetByName(ctx context.Context, params PetGetByNameParams) (Pet, error)
	// ...
}

Example generated client method signature:

type PetGetByNameParams struct {
    Name string
}

// GET /pet/{name}
func (c *Client) PetGetByName(ctx context.Context, params PetGetByNameParams) (res Pet, err error)

Generics

Instead of using pointers, ogen generates generic wrappers.

For example, OptNilString is string that is optional (no value) and can be null.

// OptNilString is optional nullable string.
type OptNilString struct {
	Value string
	Set   bool
	Null  bool
}

Multiple convenience helper methods and functions are generated, some of them:

func (OptNilString) Get() (v string, ok bool)
func (OptNilString) IsNull() bool
func (OptNilString) IsSet() bool
func (OptNilString) IsEmpty() bool

func NewOptNilString(v string) OptNilString

Recursive types

If ogen encounters recursive types that can't be expressed in go, pointers are used as fallback.

Sum types

For oneOf sum-types are generated. ID that is one of [string, integer] will be represented like that:

type ID struct {
	Type   IDType
	String string
	Int    int
}

// Also, some helpers:
func NewStringID(v string) ID
func NewIntID(v int) ID

Discriminator Inference

ogen automatically infers how to discriminate between oneOf variants using several strategies:

1. Type-based discrimination (for primitive types)

Variants with different JSON types are discriminated by checking the JSON type at runtime:

{
  "oneOf": [
    {"type": "string"},
    {"type": "integer"}
  ]
}

2. Explicit discriminator (when discriminator field is specified)

When a discriminator field is defined in the schema, ogen uses it directly:

{
  "oneOf": [...],
  "discriminator": {
    "propertyName": "type",
    "mapping": {"user": "#/components/schemas/User", ...}
  }
}

3. Field-based discrimination (automatic inference from unique fields)

ogen analyzes the fields in each variant to find discriminating characteristics:

• Field name discrimination: Variants have different field names

{
  "oneOf": [
    {"type": "object", "required": ["userId"], "properties": {"userId": {"type": "string"}}},
    {"type": "object", "required": ["orderId"], "properties": {"orderId": {"type": "string"}}}
  ]
}

• Field type discrimination: Variants have fields with the same name but different types

{
  "oneOf": [
    {
      "type": "object",
      "required": ["id", "value"],
      "properties": {
        "id": {"type": "string"},
        "value": {"type": "string"}
      }
    },
    {
      "type": "object",
      "required": ["id", "value"],
      "properties": {
        "id": {"type": "integer"},
        "value": {"type": "number"}
      }
    }
  ]
}

In this case, ogen checks the JSON type of the id field at runtime to determine which variant to decode.

• Field value discrimination: Variants have fields with the same name and type but different enum values

{
  "oneOf": [
    {
      "type": "object",
      "required": ["status"],
      "properties": {
        "status": {"type": "string", "enum": ["active", "pending"]}
      }
    },
    {
      "type": "object",
      "required": ["status"],
      "properties": {
        "status": {"type": "string", "enum": ["inactive", "deleted"]}
      }
    }
  ]
}

In this case, ogen checks the actual string value of the status field at runtime and matches it against each variant's enum values. The enum values must be disjoint (non-overlapping) for this to work. If enum values overlap, ogen will report an error and suggest using an explicit discriminator.

Const values

ogen supports the JSON Schema const keyword, which specifies that a field must have a fixed value (introduced in JSON Schema draft 6 and supported in OpenAPI 3.0+). When a field has a const value, it is encoded directly in the generated JSON encoder without requiring the struct field to be set.

Example schema with const values

components:
  schemas:
    ErrorResponse:
      type: object
      properties:
        code:
          type: integer
          const: 400
        status:
          type: string
          const: "error"
        message:
          type: string

Generated code

The generated struct includes the field, but the encoder har