Simple String Input
The simplest way to use the API is with a string input:Structured Message Input
For more complex conversations, use the message array format:Response Format
The API returns a structured response with the generated content:Server Tool Usage
For a request that invokes an OpenRouter server tool, theusage object includes server_tool_use_details. The field is omitted when no tool usage is recorded. Provider-native web search may still report web_search_requests without an OpenRouter server-tool invocation. The object reports aggregate activity for the request; web_search_requests is currently the only tool-specific counter:
tool_calls_requestedcounts OpenRouter server-orchestrated tool calls requested by the model.tool_calls_executedcounts calls that ran and returned a result.web_search_requestscounts searches performed by server-side tools. A server-orchestrated search is also included intool_calls_requested; provider-native search may only reportweb_search_requests.
usage.cost includes applicable server-tool charges.
Streaming Responses
Enable streaming for real-time response generation:Example Streaming Output
The streaming response returns Server-Sent Events (SSE) chunks:Common Parameters
Error Handling
Handle common errors gracefully:Multiple Turn Conversations
Since the Responses API is stateless, you must include the full conversation history in each request to maintain context. Replayed assistant content usesoutput_text, while user content uses input_text. Stateful parameters like store: true and previous_response_id are not supported and are rejected with a 400 error:
Required FieldsThe
id and status fields are required for any assistant role messages included in the conversation history.Conversation HistoryAlways include the complete conversation history in each request. The API does not store previous messages, so context must be maintained client-side.
Next Steps
- Learn about Reasoning capabilities
- Explore Tool Calling functionality
- Try Web Search integration