Short answers to help you integrate and operate the gateway safely.
Yes. The public contract prioritizes GET /v1/models and POST /v1/chat/completions, including bounded JSON and SSE streaming. Use only capabilities published for the selected model.
No. The client uses a platform-issued API key and a public model ID. Upstream credentials are managed server-side and are never exposed to users.
Call GET /v1/models with the current API key. The result is filtered by subscription, plan, permissions, model status, and currently usable routes.
Aliases resolve server-side to configured routes. The router still checks entitlement, capability, health, quota, and policy before selecting an actual candidate.
The gateway reserves quota before dispatch and settles one durable outcome for the public request. Internal attempts remain observable but do not become multiple user usage charges by default.
The backend checks and reserves quota before calling an upstream. Dashboard values, realtime counters, and notifications are supporting views; they do not replace gateway enforcement.
After output is committed, the gateway does not replay the request because that could duplicate content. The outcome is classified conservatively and the client receives a sanitized error.
Check the status page, retain the request ID and timestamp, then open a dashboard ticket or use the published contact channel. Never send full API keys, access tokens, or sensitive prompts.
Could not find an answer? Open a dashboard ticket or contact support.