LLM APIs
Conversational AI gateway for thread management, messaging, tool orchestration (MCP), semantic memory, and LLM proxy. (Voice sessions are in progress — not yet generally available.)
Caller identity and tenant are derived from your credentials — you never pass user or tenant identifiers in the request body. See the API Key Integration Guide.
All endpoints use POST /api/v1/llm/<method> with a JSON request body.
Field naming
Request bodies accept either snake_case or camelCase — both parse. Response bodies are
always camelCase (conversationId, activeProfileId, messageSequence), because
responses are encoded with protojson. Fields that are unset, empty, zero, or false are
omitted from the response entirely rather than sent as null — read them with a default,
not a presence check.
See the Conversations guide for thread lifecycle, async generation, and configuration. See the MCP Tools guide for tool calling, approval flows, and client-side tools. See the Memory guide for semantic memory search and conversation integration.
Authentication
- API Key: apiKeyAuth
- API Key: onBehalfOf
- HTTP: Bearer Auth
Your API key. sk_… for backend-to-backend calls, pk_… for client apps.
Never valid on its own — see the combinations under Security below.
Security Scheme Type: | apiKey |
|---|---|
Header parameter name: | X-API-Key |
The end user this call acts for. Required with an sk_… key, because a secret
key identifies your tenant and not a user; omitting it returns
401 authenticated user_id is required. The key needs the users:impersonate
scope or the call fails with 403 insufficient_scope.
Security Scheme Type: | apiKey |
|---|---|
Header parameter name: | X-On-Behalf-Of |
The end user's own JWT, issued by the OIDC provider configured on the
publishable key. Required alongside a pk_… key, and supplies the user
identity in place of X-On-Behalf-Of.
Security Scheme Type: | http |
|---|---|
HTTP Authorization Scheme: | bearer |
Bearer format: | JWT |