Responses API

POST /v1/responses

OpenAI Responses API compatible endpoint, supporting stateful multi-turn conversations, reasoning models, and tool calling. Requests and responses are passed through byte-for-byte, so official parameters work as-is with no adaptation needed.

Clients built on the Responses API — Codex CLI, the OpenAI Agents SDK, and others — can point their base_url at this service directly.

How this differs from /v1/chat/completions: the Responses API chains context server-side via previous_response_id, so you don't resend the full history each turn, and reasoning models keep their chain-of-thought context. For simple single-turn prompts, Chat Completions is simpler.

Endpoints

Request parameters

Request examples

cURL

curl https://api.aiin1.ai/v1/responses \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -d '{
    "model": "gpt-5.5",
    "input": "Hello, please introduce yourself"
  }'

Python

import openai
 
client = openai.OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.aiin1.ai/v1",
)
 
response = client.responses.create(
    model="gpt-5.5",
    input="Hello, please introduce yourself",
)
print(response.output_text)

Node.js

import OpenAI from "openai";
 
const client = new OpenAI({
  apiKey: "YOUR_API_KEY",
  baseURL: "https://api.aiin1.ai/v1",
});
 
const response = await client.responses.create({
  model: "gpt-5.5",
  input: "Hello, please introduce yourself",
});
console.log(response.output_text);

Multi-turn conversations

Pass the id returned by the previous turn as previous_response_id. The service chains the context automatically — you don't need to resend prior messages.

first = client.responses.create(
    model="gpt-5.5",
    input="My name is Alice",
)
 
second = client.responses.create(
    model="gpt-5.5",
    input="What is my name?",
    previous_response_id=first.id,   # chain the previous turn
)
print(second.output_text)   # Your name is Alice

Response

{
  "id": "nxrsp_...",
  "object": "response",
  "created_at": 1730000000,
  "model": "gpt-5.5",
  "status": "completed",
  "output": [
    {
      "type": "message",
      "role": "assistant",
      "content": [{ "type": "output_text", "text": "Hello! I am..." }]
    }
  ],
  "usage": { "input_tokens": 12, "output_tokens": 28, "total_tokens": 40 }
}

About response_id

IDs returned by this service are prefixed with nxrsp_, which differs from OpenAI's official resp_ format. The ID is signed and bound to your organization, isolating conversation data between organizations.

Things to keep in mind:

• Pass it back as-is. Use the returned id directly for previous_response_id, GET, or DELETE — the service unwraps it to the vendor's original ID automatically.
• Do not construct or modify IDs yourself, or you will get 400 invalid_request_error.
• IDs cannot be used across organizations. Using another organization's ID returns 403 permission_error.
• Do not assume the ID matches OpenAI's. If your system talks to both the official API and this service, the two sets of IDs are not interchangeable.

About /compact

POST /v1/responses/compact compacts long conversation histories. It is called automatically by Codex CLI between turns, so you normally never request it directly.

The endpoint is unavailable on some routes. In that case the service degrades gracefully: it synthesizes a history summary through the regular Responses pipeline and returns that instead, so long Codex sessions are not interrupted. The fallback is transparent to clients and returns the same response shape.

Error codes

See Error codes for the full list.