Authentication

Integrity deployment authentication and customer-provider authentication serve different purposes. Keep both explicit on model traffic.

Authenticate a model request#

POST /v1/chat/completions
x-triage-api-key: <Integrity platform key>
x-triage-session-id: <persisted task ID>
Idempotency-Key: <persisted operation ID>
Authorization: Bearer <customer provider key>
Content-Type: application/json

For Chat Completions and Responses, send the customer provider credential to the gateway as Authorization: Bearer <credential>. This also applies to configured Azure or other API-key upstreams: the gateway translates the credential into the configured upstream header. Sending only api-key to this gateway returns HTTP 401. For Anthropic Messages, the gateway accepts the provider credential in x-api-key or Authorization. The Integrity platform key still belongs in x-triage-api-key. Do not send duplicate identity headers.

Authenticate session controls#

Recovery, action authorization, action reporting, receipts, and session close use the same three Integrity identity headers. An operation ID belongs to one exact request. Reuse it only when recovering or replaying that request according to the durable operation contract.

Workspace administration uses the signed-in workspace permission model. A deployment traffic key does not grant policy administration, training, or version-management authority.

Protect and revoke credentials#

Keep keys in server-side secret storage and remove them from logs and support bundles. Use the deployment's key lifecycle controls when access changes. A revoked key or deployment cannot be replaced silently with another scope.

See Deployments and API keys and Security and evidence.