Skip to Content
👋 Willkommen bei HowToUseOpenClaw Schnellstart
GatewayOpenResponses HTTP API

OpenResponses API (HTTP)

Der OpenClaw-Gateway kann einen OpenResponses-kompatiblen Endpunkt POST /v1/responses bereitstellen. Dieser Endpunkt ist standardmäßig deaktiviert. Zuerst in der Konfiguration aktivieren.

  • POST /v1/responses
  • Gleicher Port wie der Gateway (WS + HTTP gemultiplext): http://<gateway-host>:<port>/v1/responses

Intern werden Anfragen wie ein normaler Gateway-Agenten-Lauf ausgeführt (gleicher Codepfad wie openclaw agent), Routing/Berechtigungen/Konfiguration entsprechen also Ihrem Gateway.

Authentifizierung

Nutzt die Gateway-Auth-Konfiguration. Bearer-Token mitsenden:

  • Authorization: Bearer <token>

Hinweise:

  • Bei gateway.auth.mode="token": gateway.auth.token (oder CLAWDBOT_GATEWAY_TOKEN) verwenden.
  • Bei gateway.auth.mode="password": gateway.auth.password (oder CLAWDBOT_GATEWAY_PASSWORD) verwenden.

Agenten wählen

Keine benutzerdefinierten Header nötig: Agenten-ID im OpenResponses-model-Feld kodieren:

  • model: "openclaw:<agentId>" (z. B. "openclaw:main", "openclaw:beta")
  • model: "agent:<agentId>" (Alias)

Oder einen bestimmten OpenClaw-Agenten per Header ansprechen:

  • x-openclaw-agent-id: <agentId> (Standard: main)

Erweitert:

  • x-openclaw-session-key: <sessionKey> für volle Kontrolle über das Sitzungs-Routing.

Endpunkt aktivieren

gateway.http.endpoints.responses.enabled auf true setzen:

{ gateway: { http: { endpoints: { responses: { enabled: true } } } } }

Endpunkt deaktivieren

gateway.http.endpoints.responses.enabled auf false setzen:

{ gateway: { http: { endpoints: { responses: { enabled: false } } } } }

Sitzungsverhalten

Standardmäßig ist der Endpunkt pro Anfrage zustandslos (pro Aufruf wird ein neuer Sitzungsschlüssel erzeugt). Enthält die Anfrage einen OpenResponses-user-String, leitet der Gateway daraus einen stabilen Sitzungsschlüssel ab, sodass wiederholte Aufrufe eine Agenten-Sitzung teilen können.

Request-Form (unterstützt)

Die Anfrage folgt der OpenResponses-API mit item-basiertem Input. Aktuelle Unterstützung:

  • input: String oder Array von Item-Objekten.
  • instructions: werden in den System-Prompt eingefügt.
  • tools: Client-Tool-Definitionen (Function-Tools).
  • tool_choice: Client-Tools filtern oder erzwingen.
  • stream: aktiviert SSE-Streaming.
  • max_output_tokens: Best-Effort-Ausgabelimit (anbieterabhängig).
  • user: stabiles Sitzungs-Routing.

Akzeptiert, derzeit aber ignoriert:

  • max_tool_calls
  • reasoning
  • metadata
  • store
  • previous_response_id
  • truncation

Items (input)

message

Rollen: system, developer, user, assistant.

  • system und developer werden an den System-Prompt angehängt.
  • Das zuletzt eingereichte user- oder function_call_output-Item wird zur „aktuellen Nachricht“.
  • Frühere User-/Assistant-Nachrichten werden als Verlauf für den Kontext einbezogen.

function_call_output (turn-basierte Tools)

Tool-Ergebnisse zurück an das Modell senden:

{ "type": "function_call_output", "call_id": "call_123", "output": "{\"temperature\": \"72F\"}" }

reasoning und item_reference

Werden für Schema-Kompatibilität akzeptiert, beim Aufbau des Prompts aber ignoriert.

Tools (clientseitige Function-Tools)

Tools angeben mit tools: [{ type: "function", function: { name, description?, parameters? } }]. Entscheidet der Agent, ein Tool aufzurufen, enthält die Antwort ein function_call-Output-Item. Anschließend eine Follow-up-Anfrage mit function_call_output senden, um den Turn fortzusetzen.

Bilder (input_image)

Unterstützt Base64- oder URL-Quellen:

{ "type": "input_image", "source": { "type": "url", "url": "https://example.com/image.png" } }

Erlaubte MIME-Typen (aktuell): image/jpeg, image/png, image/gif, image/webp. Max. Größe (aktuell): 10 MB.

Dateien (input_file)

Unterstützt Base64- oder URL-Quellen:

{ "type": "input_file", "source": { "type": "base64", "media_type": "text/plain", "data": "SGVsbG8gV29ybGQh", "filename": "hello.txt" } }

Erlaubte MIME-Typen (aktuell): text/plain, text/markdown, text/html, text/csv, application/json, application/pdf. Max. Größe (aktuell): 5 MB. Aktuelles Verhalten:

  • Dateiinhalt wird dekodiert und dem System-Prompt hinzugefügt, nicht der Nutzer-Nachricht, und bleibt ephemeral (nicht in der Sitzungshistorie gespeichert).
  • PDFs werden auf Text geparst. Bei wenig Text werden die ersten Seiten in Bilder gerastert und an das Modell übergeben.

Die PDF-Parsing nutzt den Node-tauglichen pdfjs-dist-Legacy-Build (ohne Worker). Der moderne PDF.js-Build erwartet Browser-Worker/DOM-Globals und wird im Gateway nicht genutzt. URL-Fetch-Standards:

  • files.allowUrl: true
  • images.allowUrl: true
  • Anfragen werden abgesichert (DNS-Auflösung, Private-IP-Block, Redirect-Limits, Timeouts).

Datei- + Bild-Limits (Konfiguration)

Defaults sind unter gateway.http.endpoints.responses einstellbar:

{ gateway: { http: { endpoints: { responses: { enabled: true, maxBodyBytes: 20000000, files: { allowUrl: true, allowedMimes: ["text/plain", "text/markdown", "text/html", "text/csv", "application/json", "application/pdf"], maxBytes: 5242880, maxChars: 200000, maxRedirects: 3, timeoutMs: 10000, pdf: { maxPages: 4, maxPixels: 4000000, minTextChars: 200 } }, images: { allowUrl: true, allowedMimes: ["image/jpeg", "image/png", "image/gif", "image/webp"], maxBytes: 10485760, maxRedirects: 3, timeoutMs: 10000 } } } } } }

Defaults bei Weglassen:

  • maxBodyBytes: 20 MB
  • files.maxBytes: 5 MB
  • files.maxChars: 200k
  • files.maxRedirects: 3
  • files.timeoutMs: 10s
  • files.pdf.maxPages: 4
  • files.pdf.maxPixels: 4.000.000
  • files.pdf.minTextChars: 200
  • images.maxBytes: 10 MB
  • images.maxRedirects: 3
  • images.timeoutMs: 10s

Streaming (SSE)

stream: true setzen für Server-Sent Events (SSE):

  • Content-Type: text/event-stream
  • Jede Ereigniszeile ist event: <type> und data: <json>
  • Stream endet mit data: [DONE]

Aktuell gesendete Event-Typen:

  • response.created
  • response.in_progress
  • response.output_item.added
  • response.content_part.added
  • response.output_text.delta
  • response.output_text.done
  • response.content_part.done
  • response.output_item.done
  • response.completed
  • response.failed (bei Fehler)

Usage

usage wird gesetzt, wenn der zugrundeliegende Provider Token-Zahlen meldet.

Fehler

Fehler nutzen ein JSON-Objekt wie:

{ "error": { "message": "...", "type": "invalid_request_error" } }

Typische Fälle:

  • 401 fehlende/ungültige Auth
  • 400 ungültiger Request-Body
  • 405 falsche Methode

Beispiele

Nicht streamend:

curl -sS http://127.0.0.1:18789/v1/responses \ -H 'Authorization: Bearer YOUR_TOKEN' \ -H 'Content-Type: application/json' \ -H 'x-openclaw-agent-id: main' \ -d '{ "model": "openclaw", "input": "hi" }'

Streaming:

curl -N http://127.0.0.1:18789/v1/responses \ -H 'Authorization: Bearer YOUR_TOKEN' \ -H 'Content-Type: application/json' \ -H 'x-openclaw-agent-id: main' \ -d '{ "model": "openclaw", "stream": true, "input": "hi" }'
Zuletzt aktualisiert am: