Authentication
Every request to /v1/** must carry an Authorization header with a Lattice application API key:
Authorization: Bearer lattice_sk_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxGetting a key
Application API keys are issued through the Management API (or the Dashboard) by an admin — not by the application itself. A key is scoped to exactly one application and inherits that application's policy (allowed models, quota, rate limit, routing strategy).
The OpenAI-compatible surface
Lattice's /v1 API deliberately mirrors OpenAI's request/response shapes so existing OpenAI SDKs and tooling work against it with only a baseURL change:
import OpenAI from 'openai';
const client = new OpenAI({
apiKey: process.env.LATTICE_API_KEY,
baseURL: 'https://gateway.internal/v1',
});tools/tool_calls, which Lattice doesn't support yet) are rejected with 400 invalid_request rather than silently ignored. Don't pass OpenAI SDK options you haven't confirmed Lattice accepts — see Chat Completions for the exact accepted field list. Auth failure responses
| Condition | Status | error.code |
|---|---|---|
No Authorization header, or not Bearer <token> | 401 | missing_api_key |
| Key doesn't match any active key, or its application is disabled | 401 | invalid_api_key |
See Errors for the full error envelope shape and every possible code.
What a key does not grant
An application key only authenticates against /v1/**. It carries no access to /management/v1/** — provisioning, usage inspection, and key issuance for other applications all require a separate management key, held only by the dashboard or trusted admin tooling.
Management API authentication
/management/v1/** uses the same Authorization: Bearer <key> mechanics, but against a distinct key type and table (management_api_keys, not api_keys). A management key is not scoped to any application — it administers the gateway itself. See Management API → Overview.