Responses
The OpenAI Responses API family and Responses operation.
Responses has its own native OpenAI API entry
The Responses operation uses /v1/responses; it is not an alias for Chat Completions. New OpenAI projects and Codex-like tools typically use this entry first. Models, usage fields, and streaming completion events follow the Responses wire contract.
Server-side Responses continuation is unsupported
Non-empty previous_response_id is currently unsupported. Do not rely on server-side stored Responses state; the client must send the complete context with every request (for example, the complete input). A non-empty value returns 400 unsupported_parameter before content filtering, billing, selection, or any upstream call. Omitting the field is recommended; null or a blank string is accepted only for compatibility.
Path
| Purpose | Method and path |
|---|---|
| Model request | POST /v1/responses |
Request example
curl https://dingjiai.com/v1/responses \
-H "Authorization: Bearer YOUR_USER_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "A_PUBLIC_MODEL_ID_AVAILABLE_FOR_RESPONSES",
"input": "Describe in one sentence what the Responses endpoint is suited for"
}'Streaming request
curl -N https://dingjiai.com/v1/responses \
-H "Authorization: Bearer YOUR_USER_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "A_PUBLIC_MODEL_ID_AVAILABLE_FOR_RESPONSES",
"stream": true,
"input": "Explain in three steps how to diagnose a failed API call"
}'When the server reads a normal completion event, streaming Responses preferentially extracts usage from the response usage in that event. An upstream disconnect, client cancellation, or delivery failure may still settle trusted partial usage or extractable output already observed by the gateway; successful chunk delivery is not required. For token-priced products, a valid non-stream success JSON object with missing or invalid usage may use an output estimate with a one-output-token minimum, even with no extractable output (including {}). Stream estimates require extractable generated output; heartbeats, empty events, and raw chunks are insufficient. A stream without trusted usage or extractable output is charged zero.
Search capability
Codex may use Search as needed during a Responses workflow. For clients, this is a Responses capability and does not require another protocol, model, or credential. The current Codex client may issue an additional POST /v1/alpha/search transport request; 8788 only transparently forwards it through the same gateway path. That request does not create separate usage, a reservation, or a ledger charge; the subsequent Responses request follows the normal usage rules on this page.
Do not hand-build a Search response or function_call_output outside the original Codex session; the Search request depends on client-generated context and call identifiers. Search reuses the eligible Responses upstream candidates by default; parameter support remains an upstream contract.
Request fields
Prop
Type
Usage and billing
Settlement reads usage.input_tokens, usage.output_tokens, and the optional usage.input_tokens_details.cached_tokens field.
The server does not trust token counts estimated by the client. A conservative estimate is used only when the response content can be confirmed valid and the product is token-priced; if it cannot be estimated safely, the request still fails closed.
Responses follows the model products published for this entry
There is currently no public, dedicated /v1/responses model list. When integrating Responses, use a public model id that the platform or an administrator has explicitly enabled for the Responses API entry. Do not treat the Chat Completions models returned by GET /v1/models as proof that those models are available for Responses.
Last updated on