OpenAI-kompatible API
Realtime-Übersetzungs-Sessions
Sprachübersetzungsmodelle (OpenAIgpt-realtime-translate) laufen auf einer eigenen
Session-Schnittstelle, die das Gateway entsprechend abbildet. Verbinden Sie sich mit
/v1/realtime/translations – oder mit /v1/realtime?intent=translation, was dieselbe Session ist –
und legen Sie die Zielsprache fest, nachdem der Socket geöffnet wurde:
session.input_audio_buffer.append eingehend,
session.output_audio.delta und session.output_transcript.delta ausgehend) und akzeptieren
PCM16-Audio mit 24 kHz. Frames werden unverändert weitergeleitet, sodass jeder Client, der gegen die
Übersetzungs-API des Providers geschrieben wurde, ohne Änderungen funktioniert.
Übersetzung ist derzeit eine OpenAI-Schnittstelle. Wird eine Übersetzungs-Session an einen Provider
geroutet, der keine anbietet, schlägt sie mit 400 fehl, statt stillschweigend eine gewöhnliche
Konversations-Session an ihrer Stelle zu öffnen.
Diese Sessions melden keine Nutzungs-Events, daher berechnet das Gateway ihre Kosten anhand des
weitergeleiteten Input-Audios zum sekundengenauen Input-Preis des Modells. WebRTC-Übersetzungs-Calls
sind die Ausnahme: Ihre Medien laufen nie durch das Gateway, daher werden sie nicht erfasst.
Realtime-Transkriptions-Sessions
Transkriptions-Sessions (/v1/realtime?intent=transcription) wählen ihr Modell in
session.update statt in der URL; der Query-Parameter model routet den Request, und das Gateway
legt die Auswahl innerhalb der Session auf dieses Modell fest.
Die meisten Transkriptionsmodelle melden ihre Nutzung im Event
conversation.item.input_audio_transcription.completed – als Tokens oder, bei Whisper-artigen
Modellen, als Sekunden –, und diese Meldung bestimmt den Preis der Session. Ein Modell, das dort
keine Nutzung angibt, meldet nichts; dann greift das Gateway auf das weitergeleitete Input-Audio zum
sekundengenauen Input-Preis zurück. Der Fallback greift nur, wenn eine Session selbst keine Nutzung
gemeldet hat, sodass eine Session nie doppelt abgerechnet wird. Wie bei der Übersetzung übertragen
WebRTC-Calls ihre Medien außerhalb des Gateways und werden nicht erfasst.
Anthropic-kompatible API
Decisions API
Verfügbar, wenn ein Provider vom Typopenai, jev oder openrouter konfiguriert ist; siehe
Decisions API.
System One API
Verfügbar, wenn ein Provider vom Typjev oder openrouter konfiguriert ist; siehe
System One API.
Gateway-Erweiterungen
Key-Verifizierung
MitGET /v1/auth/verify kann ein Dienst, der vor dem Gateway steht, einen API-Key prüfen, ohne
eine Kopie der Key-Liste vorzuhalten. Der Endpunkt ist standardmäßig deaktiviert; aktivieren Sie
ihn mit AUTH_VERIFY_ENABLED=true (server.auth_verify_enabled). Es handelt sich nicht um eine
/admin-Route, daher funktioniert er auch dann, wenn die Admin API deaktiviert ist.
401 abgelehnt; ein 200 bedeutet also, dass der Key sich erfolgreich
authentifiziert. method gibt an, welcher Mechanismus ihn akzeptiert hat: api_key ist ein
verwalteter, in der Datenbank gespeicherter Key, master_key der Bootstrap-Key aus
GOMODEL_MASTER_KEY. key_id und user_path sind nur bei verwalteten Keys vorhanden, die daran
gebunden sind.
Wo das Gateway nicht authentifizierte Aufrufer zulässt – weil überhaupt keine Authentifizierung
konfiguriert ist oder weil eine Erweiterung eine Route davon ausgenommen hat –, gibt es keinen Key
zu bestätigen. Der Endpunkt antwortet dann mit
200 und {"valid": false, "method": "none"},
statt zu behaupten, der Key sei gültig. Ein Statuscode-basierter Consumer wie forward_auth von
Caddy wertet das als erlaubt, was dem entspricht, wie das Gateway selbst diese Requests behandelt.Provider-Passthrough
MCP Gateway
Streamable-HTTP-MCP-Endpunkte (Model Context Protocol), die die konfigurierten Upstream-MCP-Server bündeln (wennMCP_ENABLED, standardmäßig aktiviert). Siehe MCP Gateway.
Admin-Endpunkte
Admin-REST- und Dashboard-Routen (/admin/*) werden unter
Admin-Endpunkte behandelt.