For AI agents: a documentation index is available at the root level at /llms.txt and /llms-full.txt. Append /llms.txt to any URL for a page-level index, or .md for the markdown version of any page.
DashboardSign Up
  • Getting Started
    • Welcome
    • Quick Start
    • Authentication
  • Native Mode
    • Overview
    • OpenAI
    • Anthropic
    • Gemini
  • Unified Mode
    • Overview
    • Python
    • TypeScript
    • cURL
  • Platform
    • Key Management
    • Rate Limits & Budgets
    • Usage & Billing
    • Error Reference
  • API Reference
DashboardSign Up
On this page
  • Key format
  • Sending your key
  • Authorization header (recommended)
  • x-api-key header
  • x-goog-api-key header
  • What happens to provider credentials
  • Key validation
  • Dashboard vs. proxy authentication
Getting Started

Authentication

How proxy keys work
Was this page helpful?
Edit this page
Previous

Native Mode

Use any provider’s SDK as-is, pointed at your gateway

Next
Built with

Every request to Gateway AI’s proxy is authenticated with a proxy key. Proxy keys are created in your dashboard and scoped to your organization.

Key format

Proxy keys look like this:

sk-proxy-a1b2c3d4e5f67890abcdef1234567890abcdef1234567890abcdef1234567890

They always start with sk-proxy- followed by 64 hex characters.

Sending your key

You can send your proxy key in any of three headers:

Authorization header (recommended)

Authorization: Bearer sk-proxy-YOUR_KEY_HERE

This is the default for the OpenAI SDK and most HTTP clients.

x-api-key header

x-api-key: sk-proxy-YOUR_KEY_HERE

This is the default for the Anthropic SDK.

x-goog-api-key header

x-goog-api-key: sk-proxy-YOUR_KEY_HERE

This is the default for the Google Generative AI (Gemini) SDK.

All three work on every endpoint. The gateway detects sk-proxy- prefixed values in any of these headers.

What happens to provider credentials

When the gateway receives your request:

  1. Your Authorization, x-api-key, x-goog-api-key, and Host headers are stripped
  2. Your proxy key is validated (active, not expired, IP allowed, etc.)
  3. The real provider API key is injected into the correct header for the target provider
  4. The request is forwarded to the provider

Your code never sees or handles the real provider API key. It stays on the server.

Key validation

Every request is checked against these rules:

CheckWhat happens
Key exists401 invalid proxy key if not found
Key is active403 key_revoked if revoked
Key not expired403 key_expired if past expiry date
IP allowed403 ip_blocked if client IP not in allowlist
Provider allowed403 provider_not_allowed if provider not in key’s allowed list
Model allowed403 model_not_allowed if model not in key’s allowed list
Rate limit429 rate_limited if RPM exceeded
Spend limit403 spend_exceeded if key spend limit reached
Credit balance403 insufficient_credits if org has no credits
Budget limit403 budget_exceeded if org budget config exceeded

Dashboard vs. proxy authentication

Gateway AI has two auth systems:

  • Proxy keys (sk-proxy-...) — for LLM proxy requests (/openai/*, /anthropic/*, /gemini/*, /v1/chat/completions)
  • Firebase JWT — for the management API and dashboard (/v1/account, /v1/keys, /v1/usage, etc.)

Your developers use proxy keys. Your dashboard and management API use Firebase authentication.