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 completion event. If at least one upstream/model chunk has been delivered, an upstream disconnect or client cancellation is still recorded as a failure reason, but settlement uses the collected partial usage or output floor. When usage is missing or invalid, a token-priced product may use a conservative lower-bound estimate.
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