Authentication

Model Gate production keys begin with mg_live_. The same key works for OpenAI-compatible and Anthropic-compatible requests.

OpenAI-compatible header

Authorization: Bearer mg_live_...
Content-Type: application/json

Use this form for /v1/chat/completions, /v1/responses, /v1/embeddings, /v1/images/generations, /v1/models, and /v1/balance.

Anthropic-compatible header

x-api-key: mg_live_...
anthropic-version: 2023-06-01
content-type: application/json

Use this form for /v1/messages and /v1/messages/count_tokens. Bearer authentication is also accepted.

Request example

curl https://api.model-gate.com/v1/models \
  -H "Authorization: Bearer mg_live_..."

Response example

{
  "object": "list",
  "data": []
}

Unauthenticated endpoints

Only service-health endpoints are unauthenticated:

GET /health
GET /health/live
GET /health/ready

Interactive browser sessions

The Model Gate account panel uses a server-side browser session that is separate from Model API keys. By default, an authenticated browser session expires after 12 hours without authenticated activity or after 7 days total, whichever comes first. The browser cookie itself remains a session cookie, so closing the browser may end it earlier depending on browser behavior.

When an account-panel page is still open after authentication expires, AJAX actions return HTTP 401 JSON with code authentication_required and the panel shows a Session expired prompt instead of treating the login page as JSON. A stale page/CSRF token returns HTTP 419 JSON with code csrf_expired and asks for a page refresh. Failed mutations, including payment initialization, are never automatically replayed after signing in or refreshing.

Account and IP security

The authenticated profile can enable TOTP two-factor authentication with WinAuth or another compatible authenticator. Business organizations may require TOTP for every member; this requirement is enabled by default for Business organizations. A completed second-factor challenge is recorded on the current browser session. Sensitive account actions such as creating/revealing/rotating credentials, changing security policy and regenerating security secrets require a recent second-factor proof when TOTP is enabled; the current product window is 15 minutes.

Enabling TOTP creates ten one-time recovery codes. Their full values are shown only when generated; Model Gate stores only hashes and atomically consumes a code after use. Regenerating recovery codes invalidates older unused codes. TOTP enrollment requires the current password when the account has one, or a recent primary OAuth/Telegram authentication for passwordless accounts. Password changes, TOTP enable/disable/reset and login-security policy changes revoke stale browser sessions. Administrators and Business owner/admin users can reset a managed user's TOTP when recovery is required; that reset signs the target's browser sessions out but does not revoke Model API credentials.

The profile presents Authenticator app (TOTP) and IP allowlists as separate security controls. Initial authenticator enrollment opens a modal and completes setup/confirmation with AJAX while retaining the normal server-side POST fallback. Login/API allowlists are edited in a separate modal and saved with AJAX after the same recent-2FA step-up policy.

The profile also supports separate login and API IP allowlists. Rules are exact IPv4/IPv6 addresses or CIDR prefixes. An empty list means no restriction. Business owners/admins may additionally define organization-wide login and API allowlists. When both personal and organization API rules exist, the request source must match both. A request rejected by an API IP policy returns HTTP 403 with code ip_not_allowed where the compatibility response format exposes an error code.

For Business credentials, the company owner remains the billing owner while each credential records a credential user (principal). The principal's active status, personal API IP allowlist and user RPM/concurrency limits apply to that key; the company balance/pricing and organization API IP policy remain company-scoped. Employee credentials must be assigned to an active group and require an executable Business permission (admin or developer, with organization owner/admin authority also accepted). billing and viewer group permissions do not execute Model API traffic.

A group administrator can manage keys in that group, but cannot reveal or rotate a secret issued to another credential principal; the principal themself and organization owner/admin can access that credential secret. If an owner-principal secret was shared with employees before 9.6.2, rotate it and issue dedicated employee-principal credentials to obtain reliable per-employee revoke/IP behavior.

TOTP protects interactive sign-in and sensitive human account actions. Password, OAuth and Telegram sign-in all use the same second-factor policy. Recovery codes may be used once in place of TOTP for sign-in or step-up. Sensitive Telegram commands require a second factor when TOTP is enrolled, and submitted codes are redacted from durable Telegram update/conversation storage. Model API requests do not prompt for or validate a TOTP code: an already issued key is authorized by the key state, credential-principal status/permissions, effective IP allowlists and runtime/billing limits.

• Store keys in environment variables or a secret manager.
• Never commit a key to Git.
• Use a separate key for each project or external user.
• Freeze or rotate a compromised key immediately.
• Model API-key secrets are shown only at creation or rotation.
• Partner API bearer tokens are also shown only at generation/rotation and are stored hash-only by Model Gate.
• Callback signing secrets are shown only at generation/rotation and are encrypted at rest; store your copy in a secret manager.
• If you enable an API IP allowlist, include every outbound NAT/egress address that may call Model Gate.