Skip to main content
POST
Die beiden APIs nicht vermischen: /v1/* ist die Inference-API (dieses Dokument, Upstream 1:1, ohne Wrapper); /api/* ist die Management-API (Guthaben/Logs usw., Antwort {success, message, data}). Wenn an anderer Stelle steht, dass /v1/messages {code, data} zurückgibt, gilt dieses Dokument.

Autorisierung

Zwei Authentifizierungsmethoden werden unterstützt — wählen Sie eine:
string
Authentifizierungs-Header im Anthropic-StilBesuchen Sie die Seite zur API-Key-Verwaltung, um Ihren API-Key zu erhalten
string
Bearer-Token-Authentifizierung (Alternative zu x-api-key)
string
API-Version (optional; funktioniert auch ohne Header)Empfohlen, um später leichter auf den offiziellen Anthropic-Endpunkt zu migrieren:Beispiel: 2025-10-01

Body

string
Standard:"claude-sonnet-4-6"
erforderlich
Model name
  • claude-opus-4-8 - Claude Opus 4.8 flagship model
  • claude-opus-4-7 - Claude Opus 4.7 flagship model
  • claude-opus-4-6 - Claude Opus 4.6 flagship model
  • claude-sonnet-4-6 - Claude Sonnet 4.6 balanced version
  • claude-opus-4-5-20251101 - Claude Opus 4.5 model
array
erforderlich
Liste von NachrichtenArray von Nachrichten, auf deren Grundlage das Modell die nächste Antwort generiert. Jede Nachricht enthält die Felder role und content.💡 Schnellausfüllen (Try-it-Bereich):
  1. Klicken Sie auf „+ Add an item”, um eine Nachricht hinzuzufügen
  2. Eingabe role: user (Benutzernachricht) oder assistant (KI-Antwort, für Mehrfach-Dialoge)
  3. Eingabe content: der Text Ihrer Nachricht
Einzelne Benutzernachricht:
Mehrfach-Dialog:
Vorbefüllte Assistant-Antwort:
integer
erforderlich
Maximale Anzahl zu generierender Tokens (pflicht, wie bei Anthropic)Maximale Anzahl an Tokens, bevor die Generierung stoppt. Das Modell kann bereits vor Erreichen dieser Grenze stoppen.Verschiedene Modelle haben unterschiedliche Maximalwerte. Minimum: 1
object
Extended-thinking-KonfigurationBei Aktivierung kann die Antwort-content thinking-Blöcke enthalten. Empfohlen ist der Standard-Modellname + dieser Parameter statt plattformseitiger -thinking-Aliase — erleichtert die Migration zum offiziellen Endpunkt ohne Codeänderungen.Wenn Thinking-Blöcke in Mehrfachdialogen zurückgesendet werden, muss signature unverändert mitgeschickt werden, sonst lehnt der Upstream ab.
string | array
SystemanweisungSystemanweisungen legen Claudes Rolle, Persönlichkeit, Ziele und Anweisungen fest.String-Format:
Strukturiertes Format:
number
Temperatur-Parameter, Bereich 0–1Steuert die Zufälligkeit der Ausgabe:
  • Niedrige Werte (z. B. 0.2): deterministischer, konservativer
  • Hohe Werte (z. B. 0.8): zufälliger, kreativer
Standard: 1.0
number
Nucleus-Sampling-Parameter, Bereich 0–1Verwendet Nucleus-Sampling. Es wird empfohlen, entweder temperature oder top_p zu verwenden, nicht beides.Standard: 1.0
integer
Top-K-SamplingSampling nur aus den Top-K-Optionen, entfernt „long tail”-Antworten mit niedriger Wahrscheinlichkeit.Nur für fortgeschrittene Anwendungsfälle empfohlen.
boolean
Streaming aktivierenBei true werden Server-Sent Events (SSE) zur Streaming-Übertragung der Antworten verwendet.Standard: false
array
Stopp-SequenzenBenutzerdefinierte Textsequenzen, bei denen das Modell die Generierung stoppt.Maximal 4 Sequenzen.Beispiel: ["\n\nHuman:", "\n\nAssistant:"]
object
MetadatenMetadaten-Objekt für die Anfrage.Enthält:
  • user_id: Benutzer-Identifikator
array
Tool-DefinitionenListe der Tools, die das Modell zur Erledigung von Aufgaben verwenden kann.Beispiel für ein Funktions-Tool:
Unterstützte Tool-Typen:
  • Benutzerdefinierte Funktions-Tools
  • Computer-Use-Tool (computer_20241022)
  • Texteditor-Tool (text_editor_20241022)
  • Bash-Tool (bash_20241022)
object
Tool-AuswahlstrategieSteuert, wie das Modell Tools verwendet:
  • {"type": "auto"}: automatische Entscheidung (Standard)
  • {"type": "any"}: muss ein Tool verwenden
  • {"type": "tool", "name": "tool_name"}: spezifisches Tool verwenden

Response

string
Eindeutiger Nachrichten-IdentifikatorBeispiel: "msg_013Zva2CMHLNnXjNJJKqJ2EF"
string
ObjekttypImmer "message"
string
RolleImmer "assistant"
array
Array von Content-BlöckenIn content wird der Blocktyp über type unterschieden. Eine Antwort kann mehrere Blöcke enthalten (z. B. bei aktiviertem Thinking: thinking + text).text-Block:
tool_use-Block:
caller ist ein neues Upstream-Feld und noch nicht in der offiziellen Dokumentation enthalten. Beim Parsen ignorieren.
thinking-Block (erscheint, wenn der Request-Body den Parameter thinking enthält):
Wenn Thinking-Blöcke in Mehrfachdialogen zurückgesendet werden, muss signature unverändert mitgeschickt werden, sonst lehnt der Upstream ab.
Nicht annehmen, dass content[0] Text ist. Bei aktiviertem Thinking kann content[0] ein Thinking-Block sein. Durchlaufen und filtern:
string
Das Modell, das die Anfrage bearbeitet hatBeispiel: "claude-sonnet-4-6"
string
Stopp-GrundMögliche Werte:
  • end_turn: natürliche Beendigung
  • max_tokens: maximale Token-Anzahl erreicht
  • stop_sequence: Stopp-Sequenz erreicht
  • tool_use: Tool aufgerufen
string | null
Ausgelöste Stopp-SequenzBei Stopp durch eine Stopp-Sequenz deren Inhalt; sonst null
object | null
Neueres Anthropic-Feld; bei normalen Anfragen null
object
Statistik zur Token-Nutzung (vollständige Struktur bei Nicht-Streaming)

Anwendungsbeispiele

Einfacher Dialog

Mehrfach-Dialog

Verwendung von Systemanweisungen

Streaming-Antwort

Tool-Nutzung

Bildverständnis

Bild im Base64-Format

Best Practices

1. Prompt Engineering

Klare Rollendefinition:
Strukturierte Ausgabe:

2. Fehlerbehandlung

3. Token-Optimierung

4. Vorbefüllung von Antworten

Verarbeitung von Streaming-Antworten

Streaming in Python

Streaming in JavaScript

Plattformunterschiede und Integrationshinweise

Antwort ohne Wrapper

Bei Erfolg gibt POST /v1/messages das Anthropic-Message-Objekt direkt zurück — ohne äußere {code, data}-Hülle. Damit sind offizielles SDK, Claude Code, Cline usw. 1:1 kompatibel.

Fehlerformat (einziger wesentlicher Unterschied zum Offiziellen)

Im Vergleich zu Anthropic: Top-Level fehlt "type": "error"; error.type ist fest apimart_error, nicht semantische Typen wie invalid_request_error. Integrationsempfehlung: Retry-Logik nicht an error.type koppeln, sondern HTTP-Status + error.code nutzen: Bei Support-Anfragen: Request-ID am Ende von error.message und Response-Header x-oneapi-request-id angeben.

Streaming-SSE

Request mit "stream": true. Ereignisreihenfolge wie offiziell: message_startcontent_block_startpingcontent_block_delta (mehrfach) → content_block_stopmessage_deltamessage_stop ⚠️ usage-Struktur unterscheidet sich zwischen Stream und Non-Stream: message_delta.usage hat typischerweise nur 4 Token-Felder, ohne cache_creation, service_tier, inference_geo. Getrennt parsen oder alle Felder optional behandeln.

Nicht implementierte Endpunkte

POST /v1/messages/count_tokens ist nicht implementiert und liefert 404. client.messages.count_tokens() des offiziellen SDK schlägt fehl. Token-Schätzung lokal vornehmen oder usage.input_tokens aus der Antwort lesen.

Unbekannte Felder ignorieren

Diese API reicht Upstream durch; Anthropic kann jederzeit Felder ergänzen (z. B. stop_details, inference_geo, caller, output_tokens_details). Keine strenge Schema-Validierung:
  • Go: kein DisallowUnknownFields()
  • Pydantic: kein extra="forbid"
  • TypeScript / Zod: .passthrough() statt .strict()

Empfehlung zu Modellnamen

Gleichnamige Modelle mit Suffix -thinking sind Plattform-Aliase. Empfohlen ist der Standardname ohne Suffix + Parameter thinking im Request-Body — erleichtert die Migration zum offiziellen Endpunkt. Weitere Request-Body-Felder entsprechen dem Offiziellen: model, messages, max_tokens (pflicht), system, temperature, top_p, top_k, stop_sequences, stream, tools, tool_choice, thinking, metadata. Semantik gemäß Anthropic Messages API.

Wichtige Hinweise

  1. API-Key-Sicherheit:
    • Speichern Sie API-Keys in Umgebungsvariablen
    • Schreiben Sie Keys niemals fest in den Quellcode
    • Rotieren Sie Keys regelmäßig
  2. Rate-Limiting:
    • Beachten Sie die API-Rate-Limits
    • Implementieren Sie Retry-Mechanismen (nach HTTP-Status)
    • Verwenden Sie exponentielles Backoff
  3. Token-Verwaltung:
    • Überwachen Sie die Token-Nutzung (usage lesen)
    • Optimieren Sie die Prompt-Länge
    • Verwenden Sie passende max_tokens-Werte
    • Bei Thinking enthält output_tokens Thinking bereits — nicht doppelt abrechnen
  4. Modellauswahl:
    • Opus: komplexe Aufgaben, die tiefes Denken erfordern
    • Sonnet: ausgewogene Leistung und Kosten
    • Haiku: schnelle Antwort, einfache Aufgaben
  5. Content-Parsing:
    • content durchlaufen und type == "text" wählen; nicht hart content[0].text annehmen
    • Liefert das Modell JSON in Markdown-Codeblöcken, ist das Modellausgabe, kein API-Wrapper (siehe FAQ unten)
  6. Inhaltsfilterung:
    • Validieren Sie Benutzereingaben
    • Filtern Sie sensible Informationen
    • Implementieren Sie Inhaltsmoderation

FAQ

Im Antwort-content ist text ein ```json ... ```-Codeblock — wie entfernen?

Das ist kein API-Strukturproblem. Im Feld text steht der rohe Modelloutput: Hält das Modell JSON für gewünscht, packt es ihn in einen Markdown-Codeblock. Die API schreibt den Modelloutput nicht um und soll das auch nicht. Für saubere strukturierte Daten gibt es drei richtige Ansätze (empfohlen absteigend):
  1. Structured Output per tools erzwingen — am zuverlässigsten; input ist bereits das geparste Objekt:
  1. Assistant-Nachricht prefillen, damit das Modell bei { weiterschreibt:
  1. Im System-Prompt klar fordern: „Nur JSON ausgeben, keinen Markdown-Codeblock“.
Code-Fences per Regex abzustreifen wird nicht empfohlen — fehlt die Fence gelegentlich, schlägt das Parsen fehl.