Responses

POST /v1/responses accepts an OpenAI Responses-style request shape. It is useful for clients that send input instead of messages, including Codex-like tools.

POST https://api.rout.my/v1/responses

Request

curl https://api.rout.my/v1/responses \
  -H "Authorization: Bearer $ROUTMY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai/gpt-5.4",
    "input": "Explain this API in one sentence."
  }'

Request fields

Field	Type	Required	Notes
model	string	Yes	Exact model ID from /v1/models.
input	string or array	Yes	Plain text or an array of input messages.
instructions	string	No	Added as a system instruction before user input.
stream	boolean	No	Set true for Responses-style SSE events.
temperature	number	No	Sampling temperature.
top_p	number	No	Nucleus sampling.
max_output_tokens	integer	No	Maximum generated output tokens.
tools	array	No	Function tools in Responses format.
tool_choice	any	No	Tool selection.
parallel_tool_calls	boolean	No	Forwarded to providers that support parallel tool calls.
reasoning	object	No	Forwarded for reasoning-capable providers; effort is also mapped to chat-compatible reasoning controls.
text	object	No	text.format is mapped to response_format; text.verbosity is forwarded when supported.
store	boolean	No	Accepted and forwarded when the upstream supports it.
service_tier	string	No	Accepted and forwarded when the upstream supports it.
prompt_cache_key / prompt_cache_retention	string	No	Accepted for OpenAI-compatible clients and forwarded when supported.
safety_identifier	string	No	Accepted for client compatibility but stripped before upstream requests.
metadata	object	No	Client metadata.
previous_response_id	string	No	Accepted for compatibility; the proxy is stateless.

Additional Responses fields are preserved where possible so Codex-style and OpenAI-compatible CLIs can send newer request shapes without the proxy rejecting the body.

Message input

{
  "model": "openai/gpt-5.4",
  "instructions": "Answer in short paragraphs.",
  "input": [
    {
      "role": "user",
      "content": "What should I check before deploying?"
    }
  ]
}

Content parts with input_text or text are converted to chat text internally.

Response

{
  "id": "resp_abc123",
  "object": "response",
  "created_at": 1744000000,
  "status": "completed",
  "model": "openai/gpt-5.4",
  "output": [
    {
      "type": "message",
      "role": "assistant",
      "status": "completed",
      "content": [
        {
          "type": "output_text",
          "text": "Check environment variables, API keys, and logs."
        }
      ]
    }
  ],
  "usage": {
    "input_tokens": 20,
    "output_tokens": 12,
    "total_tokens": 32
  }
}

Streaming

{
  "model": "openai/gpt-5.4",
  "input": "Stream a short answer.",
  "stream": true
}

Streaming responses are sent as Server-Sent Events with event objects such as response creation, output text deltas, function-call argument deltas, and completion. Each JSON data object includes a type field matching the SSE event name and a sequence_number, for example:

event: response.output_text.delta
data: {"type":"response.output_text.delta","output_index":0,"content_index":0,"item_id":"msg_123","delta":"Hello","sequence_number":5}

Stateless operations

The proxy returns response IDs for client compatibility. Persistent retrieval, cancellation, and deletion endpoints may exist for compatibility paths, but generation itself should be treated as stateless unless your client stores conversation state.