SDKs
Authentication
The generated client wires in exactly one auth scheme. It is a project-wide setting in SDK Studio, forwarded to the generator on every build, so what you see in Studio is what ships.
Schemes
| Scheme | What the client sends |
|---|---|
none | Nothing. For public APIs. |
apiKey | A key in a header |
basic | Authorization: Basic <base64 user:pass> |
bearer | Authorization: Bearer <token> |
oauth2 | A bearer token obtained through an OAuth2 flow |
bearer is the default, and the right answer for most APIs.
What callers write
const client = new AcmeClient({ token: process.env.ACME_TOKEN });The generator emits a single scheme. An API that accepts both an API key and a bearer token has to pick which one the SDK uses. If you genuinely need both, a before hook can attach the second credential.
Choosing the scheme
The spec's securitySchemes describe what the API accepts, but the SDK setting is deliberately separate: an API often accepts several schemes while the SDK should only encourage one.
If your API accepts a long-lived API key and a short-lived OAuth token, generating oauth2 steers integrators toward the safer credential without blocking the other.
Credentials never live in the SDK
The generated client reads credentials from whatever the caller passes it. Nothing is baked into the package, so an SDK published to a public registry carries no secret.
A hook is compiled into the published package. A credential hard-coded in one is published to npm or PyPI along with it. Read credentials from the caller's config or their environment instead.
Auth and the MCP server
The MCP server's operation tools call your real API and use their own environment variables (OCTRI_API_TOKEN, OCTRI_API_KEY, and friends). Those are separate from the SDK's scheme, but they should describe the same API, so an SDK generated with bearer pairs with OCTRI_API_TOKEN.