Connect your model
Client configuration
Configure endpoints, required IDs, output limits, timeouts, and recovery.
Configure one Integrity session client per task. Keep deployment identity, customer-provider authentication, and recovery behavior explicit.
Base URL and credentials#
The Integrity client accepts an explicit HTTPS deployment URL with or without a final /v1 and normalizes its model base URL. Do not use internal service addresses or construct a URL from a model name.
Use that base URL with an OpenAI-compatible client. An Anthropic client appends its own /v1/messages, so configure its base URL as the gateway origin without a trailing /v1. Match the protocol and provider already configured for the deployment.
Gateway connection options#
The gateway identifies your deployment from request headers. The deployment key travels in its own header and is never forwarded to the provider; the provider credential travels in the header that provider expects and is forwarded as-is. This is the header form, and it is what integrity.headers(operation_id) produces together with the session and operation identity.
| Header | Value | Notes |
|---|---|---|
| x-triage-api-key | The deployment key, tsk_... | Required. Never forwarded to the provider. |
| Authorization: Bearer <key> | Your provider credential (Chat Completions, Responses); x-api-key or Authorization for Messages | Required. Forwarded to the routed provider in the header it expects. |
| x-triage-session-id | The persisted session ID for the task | Required on every request in the session. |
| Idempotency-Key | The persisted operation ID for this request | Required. Reuse it only to recover this same request. |
| x-triage-client | codex, claude_code, openai_sdk, anthropic_sdk, triage_sdk, or custom | Optional. Names the calling tool in Runs. When absent the gateway infers it from the User-Agent (Codex, Claude Code, the OpenAI and Anthropic SDKs are recognized); anything else is recorded as custom. |
| x-triage-provider | A provider name | Leave it out unless the deployment has a manual routing override; then set it to that override's provider. |
For every provider and path, with runnable examples, see Connect your application. For agent tools you do not build yourself, for example Codex or Claude Code, including their configuration files and the compatibility dual-header form on /v1/messages, see Connect your agent fleet.
Composite key form (available after the gateway release of 2026-09-21). A tool that offers only a base URL and a single API key field, with no way to add a header, presents both halves as one credential: tsk_<project key>:<provider credential>, in Authorization: Bearer on the OpenAI wire or x-api-key on the Anthropic wire, with no x-triage-api-key. The gateway splits it on the first :. The tsk_ half admits the deployment exactly as the header does; only the provider half reaches the provider, in that family's credential header, and neither half is logged or persisted.
Authorization: Bearer tsk_3f9a...c21e:sk-proj-... # OpenAI wire (Chat Completions, Responses)
x-api-key: tsk_3f9a...c21e:sk-ant-... # Anthropic wire (Messages)The project half must match the deployment key pattern (tsk_ followed by URL-safe token characters). The provider half must be printable ASCII with no whitespace and no :, and must not itself be a tsk_ key. A malformed composite is refused with HTTP 401 and one of composite_project_key_invalid, composite_provider_credential_invalid, or composite_credential_ambiguous (the provider half contained a :). A bare tsk_ key sent as the provider credential is never forwarded and is refused with project_key_is_not_a_provider_credential. Prefer the header form whenever the tool can add a header, so each key travels in a header named for its purpose.
Durable identity and retry settings#
Persist a session ID for the task and an operation ID for each distinct request before dispatch. Apply integrity.headers(...) to every model request. Automatic provider retries must be disabled: use max_retries=0 in Python or maxRetries: 0 in TypeScript.
Continuous Integrity controls make one attempt and never follow redirects. Configure the provider client to reject redirects too, so deployment credentials and task data stay at the selected gateway. The Python quickstart uses DefaultHttpx2Client(follow_redirects=False); the TypeScript quickstart uses fetchOptions: { redirect: "error" }. After a timeout or disconnect, recover the original operation rather than generating a replacement ID.
The one retry the contract does authorize is announced in the body: a 503 container_not_ready or a review_capacity_exhausted hold carries automatic_retry_authorized: true and retry_after_seconds. Back off for that long (the reference client clamps it to 1–10 seconds), then re-send the same operation ID for container_not_ready or evaluate again under a new operation ID for review_capacity_exhausted. See Errors and recovery.
Output limits and timeouts#
Send a positive explicit output-token limit: max_completion_tokens or a supported max_tokens field for Chat Completions, max_output_tokens for Responses, and max_tokens for Messages. Streaming Chat Completions must also request usage.
SDK control timeouts default to 360 seconds in Python and 360,000 milliseconds in TypeScript. Align client and intermediary timeouts with the deployment's budgets. An elapsed client timeout does not prove the upstream operation stopped.
Retired configuration#
Legacy global init, classifier endpoint overrides, and classifier retry settings do not configure a continuous session. The historical check service returns HTTP 410 for retired checks. The current model gateway does not expose those routes and returns HTTP 404 for them. Use the Python or TypeScript session integration.