Responses
For file inputs, upload through the Files API, then reference the returned file_id. The gateway converts the input; provider acceptance is determined upstream.
Use {"type":"input_file","file_id":"..."} inside input[].content; images can also use type: input_image. Documents and images become URL fields. Video/audio are InOneAPI extensions described in the Files guide. A Chat upstream uses the Chat expansion rules.
Use POST /v1/responses for the OpenAI Responses-style API. It is the best fit for new text workflows that need a single input field, multimodal content parts, structured output, tool calls, or response items instead of chat choices.
Endpoint
https://api.inoneapi.com/v1/responses
# -H "X-APP-NAME: Your App Name"
# -H "X-APP-URL: https://your-app.example.com"
curl "https://api.inoneapi.com/v1/responses" \
-H "Authorization: Bearer $INONEAPI_API_KEY" \
-H "Content-Type: application/json" \
--data '{
"model": "YOUR_MODEL_ID",
"input": "Hello"
}'Parameters
| Field | Type | Required | Details |
|---|---|---|---|
| model | string | yes | Public InOneAPI model ID with Responses support enabled. |
| input | string/array | yes | User input as plain text or an array of message-style items. |
| instructions | string | no | System-level behavior guidance. Use this for durable policy or role instructions. |
| temperature | number | no | Sampling randomness. Supported range depends on the selected route. |
| top_p | number | no | Alternative sampling control. Usually tune either this or temperature. |
| max_output_tokens | number | no | Upper bound for generated output tokens. |
| stream | boolean | no | When true, returns Responses event stream chunks if the provider mapping supports streaming. |
| tools | array | no | Tool definitions such as function tools. Availability depends on the model. |
| tool_choice | string/object | no | Controls whether tools are automatic, required, or named. |
| text.format | object | no | JSON object or schema-style output control for supporting models. |
| metadata | object | no | Application metadata for your own tracing. Do not store secrets here. |
Input items
The input array can contain user, assistant, or tool-result items. Content is usually an array of typed parts.
[
{
"role": "user",
"content": [
{ "type": "input_text", "text": "Summarize this request." }
]
}
]
Response
Responses return an output array instead of chat choices. Text is usually found in output[*].content[*].text where the content type is output_text.
{
"id": "resp_...",
"object": "response",
"created_at": 1760000000,
"status": "completed",
"model": "YOUR_MODEL_ID",
"output": [
{
"type": "message",
"role": "assistant",
"content": [
{ "type": "output_text", "text": "- Check auth\n- Check routing\n- Check billing" }
]
}
],
"usage": {
"input_tokens": 20,
"output_tokens": 15,
"total_tokens": 35
}
}
Streaming and tracing
When streaming is enabled, process each event incrementally and stop only after the terminal completion event. Keep X-Gateway-Trace-ID with your application request ID so you can inspect timing, routing, retry, and token diagnostics.
Compatibility notes
Responses is not a drop-in replacement for Chat Completions. Use Chat Completions when your client expects choices[0].message; use Responses when your client expects output items. Provider mappings can normalize common fields, but unsupported tools, content part types, or response formats still return validation errors.
State and structured output limits
Responses uses text.format, not Chat’s response_format. Chat fallback only converts implemented fields; advanced structured output and hosted tools are not universally supported. InOneAPI does not expose GET/DELETE /v1/responses/{id} or Conversation APIs. Keep and resend history yourself; Chat fallback removes previous_response_id and conversation.