Clients
Authenticate an LLM Proxy client with a tenant secret
Configure a client with a tenant secret, send canonical /v2 requests, and keep management sessions and provider keys on separate boundaries.
Developers connecting an application, script, or command-line workflow to LLM Proxy.
The problem
A client integration can confuse three different credentials: the tenant secret that authorizes proxy requests, the TAuth session that authorizes management actions, and upstream provider API keys that must stay server-side.
How LLM Proxy helps
LLM Proxy authenticates public client requests with key=<tenant secret>. The bundled text clients send canonical POST /v2 messages, while the optional TAuth-protected management UI creates or manages client access and provider settings separately.
How it works
- Choose the tenant-secret source: an operator configures a static tenant, or a signed-in management user receives a generated client key once.
- Give the client a proxy base URL and tenant secret through its application configuration; the installable CLI accepts flags or LLM_PROXY_BASE_URL and LLM_PROXY_SECRET.
- Send canonical POST /v2 messages with the tenant secret in the key query parameter.
- Omit provider and model to use the authenticated tenant default, or select a configured provider when the request needs an override.
- Confirm replacement when the client key must change; future proxy requests with the prior, missing, or invalid key return 403.
Feature-to-benefit table
| Feature | Why it matters here | Example |
|---|---|---|
| One public client credential | The client authenticates to LLM Proxy with a tenant secret instead of an upstream provider key. | A script sends key=mysecret to /v2 while OpenAI, Gemini, or other provider credentials remain on the server. |
| Separate management authentication | TAuth/MPR UI sessions authorize management APIs and Settings, not a direct text request. | A signed-in user can create or replace a client key, then the application uses that key on its own proxy calls. |
| Explicit client configuration | The installable CLI reads flags or environment values; it has no user-level or system-level YAML lookup. | An application can use the optional JSON model profile only when it owns per-user provider/model selection. |
Use-case examples
Backend integration
A service stores its tenant secret in its deployment-owned configuration and sends messages through /v2.
Management onboarding
A user signs in through the shared MPR UI, copies the one-time client key, and saves a provider key before using generated request examples.
Provider-default request
A caller omits provider and model so the authenticated tenant's configured route decides the upstream provider and model.
Objections and limitations
- The bundled Go, Python, and CLI clients are text-message clients; dictation uses the separate multipart /dictate contract.
- A tenant secret is still sensitive application access material and is not an upstream provider API key.
- The optional application-owned model profile is JSON only and cannot be combined with competing provider or model inputs.
Repository evidence
curl -X POST \
-H "Content-Type: application/json" \
--data '{"messages":[{"role":"user","content":"Summarize this","order":2},{"role":"system","content":"Be concise.","order":1}],"model":"deepseek-v4-flash","max_tokens":4096}' \
"http://localhost:8080/v2?key=mysecret&provider=deepseek"Verified 2026-08-08 by Tyemirov on GitHub against README.md.
FAQ
Does the LLM Proxy client load user-level or system-level YAML?
No. The installable client uses explicit flags or LLM_PROXY_BASE_URL and LLM_PROXY_SECRET, and its optional file-based provider/model input is an application-owned JSON model profile. config.yml belongs to the service runtime.
What authenticates a public text request?
GET, POST, and POST /v2 requests authenticate with the tenant secret in the key query parameter. The bundled text clients add that parameter while sending the request body to canonical /v2.
What authenticates management Settings operations?
The optional management UI relies on the configured MPR UI and TAuth session for management APIs. That browser session is separate from the tenant secret used by public proxy requests.
Where do provider API keys belong?
Provider API keys belong in server-side runtime configuration or authenticated management storage. Public proxy requests reject provider-key-like fields instead of forwarding them upstream.
What happens when the client key is missing, invalid, or replaced?
The public proxy request returns 403 before it reaches an upstream provider.
What should I read next?
A closely related resource is Tenant-secret AI gateway for internal applications, which covers tenant secret AI gateway.
Related resources
Use this pattern in LLM Proxy
Start from the canonical API reference, then use the management surface when the workflow needs tenant or provider configuration.
Open API reference