Skip to main content

Responses API Overview

The Responses API is currently one of the main routes for newer GPT capabilities on Crazyrouter. This page only documents conclusions that were revalidated against production on 2026-03-22.
In the current production-verified scope, Claude supports only POST /v1/messages and POST /v1/chat/completions, not POST /v1/responses. Treat the Responses pages as GPT-first guidance.

Current framing

  • If you need inspectable reasoning output, prefer /v1/responses
  • If you need OpenAI-style web search, prefer /v1/responses
  • If you only need ordinary chat or want to keep an existing integration, /v1/chat/completions is still fine

Responses API vs Chat Completions API

DimensionResponses APIChat Completions API
Endpoint/v1/responses/v1/chat/completions
Input shapeinputmessages
Output shapeoutput[] item listchoices[].message
GPT reasoningVerified reasoning itemreasoning_effort works, but reasoning_content is not stable
OpenAI-style web searchVerified web_search_preview pathThe older web_search shape did not produce a stable verifiable trigger in this round
StreamingRicher event typesTraditional delta SSE

Smallest useful example

Python
from openai import OpenAI

client = OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://crazyrouter.com/v1"
)

response = client.responses.create(
    model="gpt-5.4",
    input="Explain what a REST API is in one sentence."
)

print(response.output_text)
In the current production recheck, this kind of minimal request returned:
{
  "object": "response",
  "output": [
    {
      "type": "message"
    }
  ]
}

When to prefer Responses

  • You need gpt-5.4 reasoning summaries
  • You need to verify whether the model actually triggered web_search_call
  • You want richer SSE events
Related pages:

When to keep Chat Completions

  • You already have a stable Chat Completions integration
  • You only care about the final answer, not the reasoning item
  • You are integrating Claude, Gemini, or other OpenAI-compatible models
Both APIs can coexist in the same project. In practice, the better pattern is usually not a full migration, but moving only the requests that need newer capabilities onto /v1/responses.