Create a response (OpenAI Responses API, passthrough)

OpenAI Responses API. Faithful passthrough to the provider's own Responses API for routed-commercial OpenAI and xAI models — drop-in for the official OpenAI SDK: set base_url="https://api.stav.ai/v1" and api_key=sk_stav_live_..., then call client.responses.create(...).

This is the only surface for Responses-API-only models: OpenAI's codex family (openai/gpt-5.3-codex, codex-*, o*-pro) and xAI's multi-agent models (xai/grok-4.20-multi-agent-0309), which cannot be served on /v1/chat/completions. Dual-surface models (gpt-5, o-series) are also accepted here so their reasoning features (reasoning, encrypted reasoning, built-in tools) are fully expressed.

For an OpenAI model the request body is forwarded verbatim (with the Stav model slug mapped to the provider model id) and the response / SSE stream is returned untouched.

Every other catalogue model is also accepted, and is translated onto Stav's chat dispatch path — so sovereign and open-weight models work on this surface too. Two differences apply on the translated path:

• Server-side conversation state is not supported. store: true and previous_response_id are refused by name; send the full input each turn. (Stav keeps no hidden conversation state — every turn is visible in the audit log.)
• Hosted tools the target provider cannot execute — web_search and friends — are dropped and named in the X-Stav-Dropped-Params response header. This is a capability limit of that provider's chat API, not a policy decision: a model's own native tools are accepted along with the model wherever the provider can run them.

Your workspace policy applies here too

Requests for OpenAI and xAI models are forwarded to the provider's own Responses API. They go through the same checks as every other surface: the model must be in your workspace's catalogue, and when your key policy sets a compute region, zero data retention or no training on inputs, a provider endpoint must meet it. If none does, the request is refused with 403 endpoint_not_admissible and never forwarded.

Prompt retention — store defaults to false on Stav

OpenAI's own Responses API defaults store to true, retaining your prompt and completion on OpenAI's infrastructure. Stav inverts that default. A request that does not mention store is forwarded with store: false, so nothing is retained upstream.

The consequence is deliberate and worth stating plainly: GET /v1/responses/{response_id} and GET /v1/responses/{response_id}/input_items require opting in with store: true. A workspace whose policy requires zero data retention cannot opt in: store: true is refused with 403 store_not_permitted. Retrieval is a real feature and it is yours to turn on — it is simply not on by default, because the default should not quietly park customer content in a jurisdiction you did not choose.

Otherwise, setting store explicitly — either value — is forwarded unchanged. On the translated (non-OpenAI) path store: true is refused by name, because Stav keeps no server-side conversation state of its own.

What this surface does and does not do

For an explicitly named OpenAI model this is a verbatim proxy: there is no endpoint-level failover, because there is one upstream. model: auto and model: "@workspace/router" are honoured here and route exactly as they do on /v1/chat/completions; your workspace's sovereignty floor is enforced on both paths.

Per-key rate limits apply; one inference-log row is written per call.

Request bodyapplication/json

• modelstringrequired
• inputstring | array of objects

  String or array of input items (OpenAI Responses shape).

• streamboolean
  Default: false
• storeboolean

  Retain the prompt and completion upstream so the response can be fetched later by id. Defaults to false on Stav — OpenAI's own default is true. Required for GET /v1/responses/{response_id} and its input_items.

  Default: false

Response headers

Errors

Every error code, what it means and what to do: Errors.