WebSocket events
Send client events and receive server events over a persistent Responses API WebSocket connection. Learn more about WebSocket mode.
Events sent by the client over a Responses API WebSocket connection.
Client event for creating a response over a persistent WebSocket connection.
This payload uses the same top-level fields as POST /v1/responses.
Notes:
streamis implicit over WebSocket and should not be sent.backgroundis not supported over WebSocket.
Whether to run the model response in the background. Learn more.
A system (or developer) message inserted into the model's context.
When using along with previous_response_id, the instructions from a previous
response will not be carried over to the next response. This makes it simple
to swap out system (or developer) messages in new responses.
An upper bound for the number of tokens that can be generated for a response, including visible output tokens and reasoning tokens.
The maximum number of total calls to built-in tools that can be processed in a response. This maximum number applies across all built-in tool calls, not per individual tool. Any further attempts to call a tool by the model will be ignored.
Set of 16 key-value pairs that can be attached to an object. This can be useful for storing additional information about the object in a structured format, and querying for objects via API or the dashboard.
Keys are strings with a maximum length of 64 characters. Values are strings with a maximum length of 512 characters.
Model ID used to generate the response, like gpt-4o or o3. OpenAI
offers a wide range of models with different capabilities, performance
characteristics, and price points. Refer to the model guide
to browse and compare available models.
The unique ID of the previous response to the model. Use this to
create multi-turn conversations. Learn more about
conversation state. Cannot be used in conjunction with conversation.
Reference to a prompt template and its variables. Learn more.
Used by OpenAI to cache responses for similar requests to optimize your cache hit rates. Replaces the user field. Learn more.
gpt-5 and o-series models only
Configuration options for reasoning models.
A stable identifier used to help detect users of your application that may be violating OpenAI's usage policies. The IDs should be a string that uniquely identifies each user, with a maximum length of 64 characters. We recommend hashing their username or email address, in order to avoid sending us any identifying information. Learn more.
If set to true, the model response data will be streamed to the client as it is generated using server-sent events. See the Streaming section below for more information.
What sampling temperature to use, between 0 and 2. Higher values like 0.8 will make the output more random, while lower values like 0.2 will make it more focused and deterministic.
We generally recommend altering this or top_p but not both.
Configuration options for a text response from the model. Can be plain text or structured JSON data. Learn more:
An integer between 0 and 20 specifying the maximum number of most likely tokens to return at each token position, each with an associated log probability. In some cases, the number of returned tokens may be fewer than requested.
An alternative to sampling with temperature, called nucleus sampling, where the model considers the results of the tokens with top_p probability mass. So 0.1 means only the tokens comprising the top 10% probability mass are considered.
We generally recommend altering this or temperature but not both.
This field is being replaced by safety_identifier and prompt_cache_key. Use prompt_cache_key instead to maintain caching optimizations.
A stable identifier for your end-users.
Used to boost cache hit rates by better bucketing similar requests and to help OpenAI detect and prevent abuse. Learn more.
These events use the same payloads over WebSocket and HTTP streaming.
Emitted when a new content part is added.
Emitted when a content part is done.
Emitted when there is an additional text delta.
Emitted when text content is finalized.
Emitted when there is a partial refusal text.
Emitted when refusal text is finalized.
Emitted when function-call arguments are finalized.
Emitted when a file search call is initiated.
Emitted when a file search is currently searching.
Emitted when a file search call is completed (results found).
Emitted when a web search call is initiated.
Emitted when a web search call is executing.
Emitted when a web search call is completed.
Emitted when a new reasoning summary part is added.
Emitted when a delta is added to a reasoning summary text.
Emitted when a reasoning summary text is completed.
Emitted when a delta is added to a reasoning text.
Emitted when a reasoning text is completed.
Emitted when an image generation tool call has completed and the final image is available.
Emitted when an image generation tool call is actively generating an image (intermediate state).
Emitted when an image generation tool call is in progress.
Emitted when there is a delta (partial update) to the arguments of an MCP tool call.
Emitted when the arguments for an MCP tool call are finalized.
Emitted when an MCP tool call has completed successfully.
Emitted when an MCP tool call has failed.
Emitted when an MCP tool call is in progress.
Emitted when the list of available MCP tools has been successfully retrieved.
Emitted when the attempt to list available MCP tools has failed.
Emitted when the system is in the process of retrieving the list of available MCP tools.
Emitted when the code snippet is finalized by the code interpreter.
Emitted when an annotation is added to output text content.
Event representing a delta (partial update) to the input of a custom tool call.
Event indicating that input for a custom tool call is complete.