Skip to content

Authentication & API keys

How sessions, API keys and credential isolation work on SERPforAI.

Two different credentials

SERPforAI uses two credentials that are easy to confuse but serve different purposes:

CredentialWhere it livesWhat it is for
Session tokenYour browser’s local storageSigning in to the dashboard and playground
API key (userKey)Your browser’s local storage, and your own servers once you copy it outThe Authorization: Bearer header on /v1/* calls

Both the session token and your API key are stored in local storage, and the dashboard and playground call the API directly from your browser - there is no server-side proxy in front of your key. This is why the key is visible (masked, with a reveal toggle) on /dashboard/keys: treat it like a password, and never commit it or a screenshot of it to a public repository.

Signing in

Three options, all ending in the same session token stored in local storage:

  1. Email + password - the password is hashed with SHA-256 in your browser before it is sent.
  2. Email + code - request a six digit code, then sign in with it.
  3. Google - a two step handshake that exchanges a one-time state for your session.

Managing API keys

From /dashboard/keys you can:

  • Create a key with a label such as production or ci.
  • Regenerate a key, which invalidates the old value immediately.
  • Delete a key. The primary key cannot be deleted, only regenerated.

Keys are issued and stored by the backend. This website never generates key material and never stores a copy of it.

Rotating a leaked key

If a key is exposed, regenerate it from the dashboard. The previous value stops working right away, so update your deployment secrets first, then rotate.

Rate limits

Sensitive endpoints - sign in, registration, verification codes, search and reader calls - are rate limited per IP address. Exceeding a limit returns HTTP 429. Application-level failures still return HTTP 200 with a non-zero code.