Skip to Content
API AccessChat Completions

Chat completions

POST /v1/chat/completions
Content-Type: application/json
Authorization: Bearer sk-steinkauz-live-...

Request and response bodies follow the OpenAI Chat Completions API  for supported fields. For parameter reference, streaming behavior, and response structure, see the OpenAI documentation:

Steinkauz AI supports the common OpenAI fields, including sampling controls, token limits, stop sequences, penalties, function tools with strict, tool_choice, parallel_tool_calls, structured output, reasoning_effort, verbosity, user, store, and string metadata. Unsupported parameters return 400 invalid_request_error.

Non-streaming

curl -sS "$STEINKAUZ_BASE_URL/v1/chat/completions" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $STEINKAUZ_API_KEY" \
  -d '{
    "model": "vercel-ai-gateway/openai/gpt-5.5",
    "messages": [{ "role": "user", "content": "Hello 👋" }]
  }'

Streaming

Set "stream": true. The response is text/event-stream with chat.completion.chunk objects, ending with data: [DONE]. To receive token counts, also send "stream_options": { "include_usage": true }. Steinkauz then emits the finish chunk followed by one final chunk whose choices array is empty and whose usage object contains totals. Earlier chunks carry usage: null. See OpenAI streaming  for the event format.

curl -sS -N "$STEINKAUZ_BASE_URL/v1/chat/completions" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $STEINKAUZ_API_KEY" \
  -d '{
    "model": "vercel-ai-gateway/openai/gpt-5.5",
    "messages": [{ "role": "user", "content": "Hello 👋" }],
    "stream": true,
    "stream_options": { "include_usage": true }
  }'

The usage object includes prompt_tokens, completion_tokens, and total_tokens. When the provider reports them, it also includes prompt_tokens_details.cached_tokens and completion_tokens_details.reasoning_tokens. Non-streaming responses include the same usage shape directly on the completion object.

Tools

Function tools and tool_choice are supported where the underlying model and provider allow them. Client applications execute their tools; the Platform records reported tool activity.

OpenAI SDK (Python)

from openai import OpenAI
 
client = OpenAI(
    api_key="sk-steinkauz-live-YOUR_SECRET",
    base_url="https://platform.steinkauz.ai/v1",
)
 
completion = client.chat.completions.create(
    model="vercel-ai-gateway/openai/gpt-5.5",
    messages=[{"role": "user", "content": "Hello 👋"}],
)
print(completion.choices[0].message.content)

OpenAI SDK (JavaScript)

import OpenAI from "openai";
 
const client = new OpenAI({
  apiKey: process.env.STEINKAUZ_API_KEY,
  baseURL: "https://platform.steinkauz.ai/v1",
});
 
const completion = await client.chat.completions.create({
  model: "vercel-ai-gateway/openai/gpt-5.5",
  messages: [{ role: "user", content: "Hello 👋" }],
});
 
console.log(completion.choices[0]?.message?.content);

Data sensitivity

Standard Completions uses the API key’s default data class. To raise sensitivity for one request, send a custom header (not a body field):

X-Steinkauz-Data-Sensitivity: D2_CONFIDENTIAL

The value cannot go below the key’s minimum floor. See API routing policy. Responses include X-Steinkauz-Data-Sensitivity and X-Steinkauz-Policy-Decision-Id.

Session and Turn ids

Completions may include optional session_id and turn_id (UUIDs) on the JSON body. Both are echoed on the non-stream completion object (next to id and usage) and on each stream chat.completion.chunk. Stock OpenAI SDKs ignore unknown fields; pass them with extra_body when you want to pin:

completion = client.chat.completions.create(
    model="vercel-ai-gateway/openai/gpt-5.5",
    messages=[{"role": "user", "content": "Hello 👋"}],
    extra_body={
        "session_id": session_id,
        "turn_id": turn_id,
    },
)
session_id = completion.session_id
turn_id = completion.turn_id

Transcripts are recorded even when IDs are omitted. Matching conversation history can continue one of the key’s 100 most recently active API sessions; otherwise a new session is created. Automatic matching does not create branches. Use an explicit session_id belonging to the same key when you need to control continuation, rewinds or branching.

A turn groups a user message with its resulting model and tool activity. Tool-loop follow-ups that append only assistant/tool messages reuse turn_id; a new user message starts a new turn. Each follow-up request appears as a separate step in Activity.

Client tool results

Report a tool result using the same Steinkauz API key that received the call. Tool-call IDs are scoped to that key and its creating user: another key, member, or organization can reuse call_1 without changing your tool evidence. Results can arrive in a later session under the same key. Use a fresh call ID for a genuinely new invocation within that key.

Call and result replay preserves the first successful output. Once tool content is purged, expired, or explicitly erased, a late result cannot restore it; correlation metadata remains available.

Usage tracking

Successful completions create activity records for your active organization, attributed to the API key used. Open Activity to view request decisions and usage. You can inspect model and provider, token counts, cost, duration, tool calls where applicable, and the API key label.

Usage is recorded for your active organization while you are billed by your providers directly. Optional BYOK Budgets apply when configured. A customer-owned Gateway connection still needs your Gateway API key. See Usage Budgets and Usage, costs, and activity details.

ModelsResponses