Authentication

Every request is authenticated with an API key. Create a key in the console, send it on each request, and you can call any model your key has access to.

Get an API key

Keys are issued and managed in the console:

• Console: https://swato.ai/login

A key looks like sk-.... Treat it like a credential and keep it secret.

Send the key on a request

Different protocol surfaces use different headers.

The OpenAI-compatible and Anthropic-compatible surfaces both use the standard Authorization: Bearer header:

Authorization: Bearer sk-...

The Gemini native surface (/v1beta) follows Gemini's own convention: the x-goog-api-key header, or a ?key= query parameter:

x-goog-api-key: sk-...

GET /v1beta/models?key=sk-...

curl example

Send a request to the OpenAI-compatible surface with the Bearer header:

curl https://swato.ai/v1/chat/completions \
  -H "Authorization: Bearer $SWATO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "<see GET /v1/models for the exact id>",
    "messages": [{"role": "user", "content": "Hello"}]
  }'

The equivalent on the Gemini native surface:

curl "https://swato.ai/v1beta/models/<model>:generateContent" \
  -H "x-goog-api-key: $SWATO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "contents": [{"parts": [{"text": "Hello"}]}]
  }'

Keys, groups, and platforms

This is the key mental model for how authentication behaves. Read it carefully.

Every API key belongs to a group, and every group is bound to a platform: OpenAI / Anthropic / Google. The platform decides which endpoints the key can use. The same endpoint auto-routes based on your key's group platform, so which protocol surface you use is tied to the key you call with.

Key group platform	Protocol surface	Typical endpoints
OpenAI	OpenAI-compatible	/v1/chat/completions, /v1/responses, /v1/images/generations, /v1/images/edits
Anthropic	Anthropic-compatible	/v1/messages, /v1/messages/count_tokens
Google	Gemini native	/v1beta/models/{model}:{action}

Cross-platform calls fail. For example, the image endpoints (/v1/images/generations, /v1/images/edits) are open to OpenAI-platform groups only; a key from a non-OpenAI group gets a 404 on those endpoints.

GET /v1/models and GET /v1/usage are shared across platforms. To confirm which models your key can actually call, trust the response from GET /v1/models.

TIP

For how routing picks an upstream by your key's group platform and how failover works, see Routing and fallback.

Security best practices

• Store keys in environment variables. Do not hardcode sk-... into source.
• Never commit keys to version control, and never ship them in client-side code (browser, mobile, or desktop). If a key is exposed, rotate it in the console immediately.
• Use a separate key per app or use case so you can trace and revoke by purpose.
• Proxy these requests through your own backend so the key stays server-side.

# Read from the environment, never hardcode
export SWATO_API_KEY="sk-..."

Authentication failures

A missing or invalid key returns 401 Unauthorized, with a body roughly like:

{
  "error": {
    "message": "Invalid API key",
    "type": "invalid_request_error",
    "code": "invalid_api_key"
  }
}

On a 401, check that the key is complete and correctly spelled, that it has not been revoked in the console, and that you are using the right header (Authorization: Bearer for the OpenAI/Anthropic surfaces, x-goog-api-key for the Gemini native surface).