API kompatybilne z OpenAI
Sesje tłumaczenia w czasie rzeczywistym
Modele tłumaczenia mowy (OpenAIgpt-realtime-translate) działają na własnym
interfejsie sesji, więc gateway go odzwierciedla. Połącz się z /v1/realtime/translations
– albo z /v1/realtime?intent=translation, co jest tą samą sesją – i ustaw
język docelowy po otwarciu socketu:
session.input_audio_buffer.append
na wejściu, session.output_audio.delta i session.output_transcript.delta na wyjściu)
i przyjmują audio PCM16 24 kHz. Ramki są przekazywane dosłownie, więc każdy klient napisany
pod API tłumaczenia providera działa bez zmian.
Tłumaczenie jest obecnie interfejsem OpenAI. Skierowanie sesji tłumaczenia do
providera, który go nie obsługuje, kończy się błędem 400, zamiast po cichu otworzyć
w jej miejsce zwykłą sesję konwersacji.
Te sesje nie raportują zdarzeń użycia, więc gateway wycenia je na podstawie
przekazanego audio wejściowego, według stawki modelu za sekundę wejścia. Wyjątkiem są
połączenia tłumaczenia przez WebRTC: ich media nigdy nie przechodzą przez gateway,
więc nie są mierzone.
Sesje transkrypcji w czasie rzeczywistym
Sesje transkrypcji (/v1/realtime?intent=transcription) wybierają model w
session.update, a nie w URL; parametr zapytania model kieruje
request, a gateway przypina do niego wybór dokonany w sesji.
Większość modeli transkrypcji raportuje użycie w zdarzeniu
conversation.item.input_audio_transcription.completed – w tokenach albo
w sekundach dla modeli typu whisper – i ten raport służy do wyceny sesji. Model,
który tam pomija użycie, nie raportuje niczego, więc gateway wraca do przekazanego
audio wejściowego, według stawki za sekundę wejścia. Ten mechanizm zapasowy działa
tylko wtedy, gdy sesja nie zaraportowała własnego użycia, więc sesja nigdy nie jest
rozliczana dwukrotnie. Podobnie jak przy tłumaczeniu, połączenia WebRTC przesyłają
media poza gatewayem i nie są mierzone.
API kompatybilne z Anthropic
Decisions API
Dostępne, gdy skonfigurowany jest provideropenai, jev lub openrouter; zobacz
Decisions API.
System One API
Dostępne, gdy skonfigurowany jest providerjev lub openrouter; zobacz
System One API.
Rozszerzenia gatewaya
Weryfikacja klucza
GET /v1/auth/verify pozwala usłudze stojącej przed gatewayem sprawdzić klucz API
bez przechowywania kopii listy kluczy. Endpoint jest domyślnie wyłączony; włącz go
przez AUTH_VERIFY_ENABLED=true (server.auth_verify_enabled). Nie jest to trasa
/admin, więc działa także wtedy, gdy Admin API jest wyłączone.
401, więc 200 oznacza, że klucz się uwierzytelnia.
method wskazuje, który mechanizm go zaakceptował: api_key to zarządzany klucz zapisany
w bazie danych, master_key to klucz startowy z GOMODEL_MASTER_KEY. key_id
i user_path są obecne tylko dla zarządzanych kluczy, które mają je przypisane.
Tam, gdzie gateway wpuszcza nieuwierzytelnionych wywołujących – gdy uwierzytelnianie
nie jest w ogóle skonfigurowane albo gdy rozszerzenie wyłączyło z niego daną trasę – nie ma
klucza do potwierdzenia, a endpoint odpowiada
200 z
{"valid": false, "method": "none"}, zamiast twierdzić, że klucz jest prawidłowy.
Konsument kodów statusu, taki jak forward_auth w Caddy, traktuje to jako zezwolenie,
zgodnie z tym, co sam gateway robi z takimi requestami.Passthrough do providera
MCP Gateway
Endpointy MCP (Model Context Protocol) w trybie Streamable HTTP, agregujące skonfigurowane upstreamowe serwery MCP (gdyMCP_ENABLED, domyślnie włączone). Zobacz
MCP Gateway.
Endpointy administracyjne
Trasy Admin REST i dashboardu (/admin/*) są opisane w
Endpointach administracyjnych.