Skip to main content
Most integrations should use an API key.

API key format

New keys use the format:
sk-nano-<uuid>
Some older accounts may still have legacy keys (a plain UUID). Both formats are accepted.

Send your key (headers)

Use one of these headers on every request:
  1. Authorization: Bearer <API_KEY> (recommended)
  2. X-API-Key: <API_KEY>
Example:
curl "https://nano-gpt.com/api/v1/models" \
  -H "Authorization: Bearer sk-nano-YOUR_API_KEY"

Common errors

  • 401 Unauthorized: Missing/invalid/revoked API key (or your key is inactive/expired, if your account has expiration enabled)
  • 403 Forbidden: API key browser-origin restriction failed (api_key_origin_not_allowed)
  • 429 Too Many Requests: Rate limit exceeded (per-second throughput, or a per-key daily cap if configured)
For rate-limit details, see Rate Limits.

Getting an API key

Create and manage API keys in the NanoGPT dashboard: https://nano-gpt.com/api

CLI Authentication (Device Login)

If you’re building a CLI, use device login so users can approve access in a browser and your CLI receives an API key (sk-nano-...). See: CLI Device Login

OAuth PKCE (Sign in with NanoGPT)

If you’re building a third-party app, local tool, coding agent, or generic OAuth client, use OAuth PKCE so users can approve access in NanoGPT instead of manually creating and pasting an API key. OAuth returns an app-specific NanoGPT API key (sk-nano-...) that your app sends as:
Authorization: Bearer sk-nano-...
See: OAuth PKCE

Web App Sign-In (Browser)

If you are using the NanoGPT web app, sign-in is handled via browser sessions. Supported sign-in methods include:
  • OAuth (GitHub, Google)
  • Email one-time code (magic link / verification code)
  • Email/password (or username/password, where supported)
  • Passkey (WebAuthn)
If you are calling the API from a backend service, prefer API keys instead of relying on browser cookies.

API Key Security Best Practices

  • Store keys in environment variables (for example: NANOGPT_API_KEY).
  • Never commit keys to git or ship them in client-side code.
  • Prefer Authorization: Bearer ... over putting keys in URLs.
  • For browser-based apps, set Allowed browser origins when creating the API key so the key is only accepted from your app’s origin. Prefer backend calls or OAuth PKCE when possible; do not embed unrestricted API keys in client-side code.
  • Use separate keys per app/environment so you can revoke access without breaking everything.
  • Set spending and request limits (if available for your account) to cap blast radius.