Chat-Completions (einheitlicher Compat-Endpunkt)

Hinweis

Der Endpunkt verlangt einen Token des Gateways in der Kopfzeile Authorization: Bearer <token>, solange am Gateway auth_required: true eingestellt ist. Das ist die Voreinstellung.

Senden Sie die Anfrage als POST an den Pfad /v1/{tenant}/{gateway}/compat/chat/completions.

Beschreibung

Der Endpunkt nimmt eine Chat-Anfrage entgegen. Das Gateway bestimmt den Anbieter selbst aus dem Modellnamen über den Namenspräfix. Als Auffangregel dient OpenRouter. Die Antwort trägt in jedem Fall das Schema von OpenAI, unabhängig davon, welcher Anbieter die Anfrage bearbeitet hat. Eine bestehende Anwendung mit dem SDK von OpenAI wechselt auf diesen Endpunkt, indem sie ausschließlich die base_url ändert.

Anfrage

Die folgenden Parameter sind verfügbar:

Parameter	Ort	Typ	Erforderlich	Beschreibung
tenant	Pfad	string	ja	Slug des Mandanten aus dessen Feld slug.
gateway	Pfad	string	ja	Slug des Gateways aus dessen Feld slug.
x-aig-byok-alias	Kopfzeile	string	nein	Wählt den hinterlegten eigenen Anbieter-Schlüssel für diese Anfrage. Ohne Angabe gilt default. Die Kopfzeile ist erforderlich, wenn zu einem Anbieter mehrere Schlüssel unter verschiedenen Aliasen hinterlegt sind.
x-aig-extensions	Kopfzeile	string	nein	Schaltet für eine Anfrage im Datenstrom den Nebenkanal aig_* des Gateways frei, der die Gedankengänge, die Telemetrie der Tools, die Quellen sowie die Hinweise zu PII und Tools führt. Das Gateway erkennt genau die Werte 1, true, yes und on. Jeder andere Wert, auch 0 und ein leerer Wert, ist zulässig und gilt als nicht gesetzt. Die Antwort ist dann ein reiner Datenstrom im Schema von OpenAI. Ein gültiges x-aig-turn-id schaltet den Nebenkanal ebenfalls frei.
x-aig-meta-*	Kopfzeile	string	nein	Eigene Metadaten zu dieser Anfrage. Jede Kopfzeile der Form x-aig-meta-{key} steht im Protokolleintrag und lässt sich über {"field": "meta.{key}", "op": "eq", "value": "..."} als Bedingung einer Routing-Regel verwenden.
x-aig-collect-log-payload	Kopfzeile	string	nein	Mit false hält das Gateway den Rumpf der Anfrage und der Antwort für diese eine Anfrage nicht im Protokoll fest. Die Kopfzeile eignet sich für Anfragen mit schützenswerten Daten, auch wenn am Gateway log_payloads: true eingestellt ist.

Beispiel

Beispiel für den Rumpf der Anfrage:

{
  "model": "gpt-4o",
  "messages": [
    {
      "role": "system",
      "content": {},
      "name": "string",
      "tool_calls": [
        {}
      ]
    }
  ],
  "stream": false,
  "temperature": 0.7,
  "max_tokens": 1024,
  "top_p": 0.0,
  "n": 1,
  "stop": {},
  "tools": [
    {}
  ],
  "tool_choice": {},
  "response_format": {
    "type": "text"
  },
  "user": "string",
  "metadata": {}
}

Antworten

Der Endpunkt beantwortet die Anfrage mit den folgenden Statuscodes:

Statuscode	Beschreibung
200	Antwort der Chat-Completion, bei stream=true als SSE-Datenstrom.
400	Ein Guardrail hat die Anfrage blockiert, oder die Anfrage ist ungültig.
401	Der Token fehlt oder ist ungültig.
403	Der Token ist gültig, besitzt aber die Berechtigung nicht, oder die IP-Adresse steht nicht auf der Freigabeliste.
424	provider_key_missing: das gewählte Modell läuft über einen Anbieter, der einen API-Schlüssel verlangt. Für dieses Gateway und diesen Alias ist keiner hinterlegt. Die Administration muss einen Anbieter-Schlüssel hinterlegen. Das Gateway meldet den Fehler, bevor es den Anbieter aufruft.
429	Das Ratenlimit oder das Budget ist überschritten.
502	Fehler des vorgelagerten Anbieters. Alle Wiederholungen und Ausweichwege sind erschöpft.