SDKs

Client shape

Client shape is what a caller actually types. These settings decide whether your SDK reads like client.users.list() or listUsers(), and whether arguments arrive as an object or positionally.

You'll find them in SDK Studio → Customize SDK Features. Each one shows a live code preview, so you can see the effect before you build.

Client style

Client style decides the top-level surface.

import { listUsers } from "@acme/api";

const users = await listUsers({ limit: 10 });

Standalone functions you import and call directly. Tree-shakeable, no client object to construct. The default.

Namespace

Namespace decides how operations are grouped once the surface is namespaced.

Option	Result
`tags`	Group by your OpenAPI tags. `users.list()`
`path`	Group by URL path segments. `api.users.list()`

Tags beat paths for most APIs

Tags are authored deliberately; paths are an accident of routing. If your spec tags its operations, tags gives better group names. path is the fallback when tags are sparse.

Method naming

Method naming only matters under a namespace.

Option	Result
`short`	Strips the namespace word so it isn't repeated. `getBalance` tagged `balance` becomes `balance.get()`. The default.
`full`	Keeps the operation id intact. `balance.getBalance()`

Reach for full when your operation ids are already well named and stripping them loses meaning.

Both options read from your operation ids

Every naming setting here is downstream of the operationId in your spec, so a clear, verb-first id is worth more than any option on this page. Ten habits for writing great OpenAPI specs starts there.

Argument style

Argument style decides how parameters reach a method.

await users.list({ limit: 10, cursor: "abc" });

All arguments in one options object. Self-documenting, order-free, and adding an optional parameter later isn't a breaking change. The default.

Folder structure

Folder structure decides how generated source is laid out on disk. It changes nothing at the call site, only what someone reading the SDK repo sees.

Option	Layout
`flat`	One surface, all methods together. The default.
`tags`	A folder per OpenAPI tag
`path`	A folder per URL path segment

Apply to every language

Most of these settings can differ per language, and Studio has an Apply to every language control next to each one.

Set it once, apply to all, then override the exceptions

Client style and namespace usually want to be consistent across languages so your docs and examples match. HTTP engine and data-model style are language-specific by nature and shouldn't be forced.

Precedence is narrowest-first: a per-endpoint override beats a per-language setting, which beats the project default.

Per-endpoint overrides

Selecting an endpoint in Studio gives you controls that apply to just that method:

Output detail

Three per-language settings control how much the generated source explains itself.

Setting	Options	Default
Doc comments	`full` (powers editor tooltips), `minimal` (leaner files)	`full`
File header	`omit`, `include` (a DO-NOT-EDIT banner)	`omit`
Usage example	`full`, `concise`	`full`

Turn File header on when the SDK lives in a repo where someone might try to hand-edit it.

Authentication

Wire the auth scheme into the client.

Per-language options

Engines, data-model styles, and language-only settings.