Generated clients

If you are exploring the API with grpcurl or using the HTTP API, you can skip this page.

Use generated clients when your integration depends on:

• streaming RPCs
• bytes fields and large binary payloads
• long-lived subscriptions
• strong typing in Go, Python, Rust, TypeScript, Java, Kotlin, C#, or another protobuf-capable language

What matters

For the public gRPC API, the protobuf contract is the canonical wire-level definition.

That matters in practice because:

• request and response messages come from the protobuf schema, not from this prose
• generated stubs are the safest way to handle streaming and binary-heavy RPCs
• only the documented public services and RPCs are part of the supported integration surface

If a service or method is not documented under Public surface, do not treat it as part of the supported API.

When to use generated clients instead of grpcurl

Use grpcurl for:

• discovery
• smoke checks
• support and debugging
• simple unary calls

Use generated clients for:

• file reads and writes
• tarball import and export
• source archive uploads
• message-bus subscriptions
• any integration that depends on streaming or bytes payloads

Using generated clients

• Use generated clients when your integration depends on streaming RPCs or binary-heavy payloads.
• Use Public surface as the reference for the supported services and RPCs.
• Send auth metadata and client identity headers as described in Auth and transport.

Keep to the documented API

• Use Public surface as the reference for the supported services and RPCs.
• Use grpcurl for discovery, inspection, and smoke checks.
• Use generated clients for streaming calls and binary-heavy workflows such as file reads and writes, tarball import and export, and source archive upload.