Skip to main content
The SDK is proto-first: nothing in the public surface is hand-written. Every client, doc, and HTTP handler is generated from a single set of .proto files using buf v2 and sebuf.

Repository layout

Source of truth (edited by hand)

Generated (never edited, but committed)

Generated code is committed so consumers can depend on the repo directly without running the toolchain.

Build pipeline

make generate runs buf generate, which fans out to nine plugins: Post-processing scripts inject HTTP path metadata into the TypeScript interfaces, strip @Generated annotations from Java, and emit __init__.py files for Python packages.

HTTP shape

Every RPC compiles into a stable path defined in the proto via sebuf.http. Reads are GET, mutations and batch operations are POST:
The convention follows AIP-style: single-resource reads are GET with path parameters; multi-resource batch reads use POST with :batchGet suffix and a typed body. The full path/method mapping for every operation is in the API Reference.

Versioning

  • Proto packages are versioned — every package is sdk.{service}.v1. Breaking changes ship as v2 packages alongside v1 until consumers migrate.
  • make breaking runs against main — any breaking change to v1 fails CI.
  • Generated code follows proto versioning — TS/Go/Swift packages export typed namespaces matching the proto packages.
See Versioning for the deprecation policy.

Why proto-first

  • One source, many surfaces. OpenAPI, REST clients, and HTTP handlers stay in lock-step — they’re all derivatives of the same .proto.
  • Strict contracts. Validation rules (buf.validate) live in the proto and apply identically on every client and server.
  • Documentation by construction. Every field/message/RPC has a leading comment (enforced by buf lint COMMENTS), so the OpenAPI you import already has descriptions on every operation.