> ## Documentation Index
> Fetch the complete documentation index at: https://docs.spoofsense.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# How SpoofSense API Authentication Works: Keys & Tokens

> Learn how SpoofSense secret keys and short-lived session tokens work, when to use each, and how to keep credentials secure in your integration.

SpoofSense uses two kinds of credentials that map to two trust levels: long-lived **secret keys** for your server and short-lived **session tokens** for your client. Understanding which credential to use — and where to keep it — is the first step in a secure integration.

## Secret keys (`sk_live_…`)

Created in the console under **Dashboard → API keys**. Send a secret key on every server-side call using either the `Authorization: Bearer` header or the `x-api-key` header — both are equivalent:

```bash theme={null}
# Bearer token (preferred)
curl https://api.spoofsense.ai/v1/liveness_detection \
  -H "Authorization: Bearer $SPOOFSENSE_API_KEY" \
  -F "file=@selfie.jpg"
```

```bash theme={null}
# x-api-key header (equivalent)
curl https://api.spoofsense.ai/v1/liveness_detection \
  -H "x-api-key: $SPOOFSENSE_API_KEY" \
  -F "file=@selfie.jpg"
```

* The plaintext key is shown **once** at creation; only a SHA-256 hash and the last four characters are stored. Lost keys can't be recovered — revoke and create a new one.
* A revoked or disabled key returns `401 UNAUTHORIZED`.
* When your credit balance reaches zero, keys stop working until you top up ([Credits & billing](/guides/credits)).

<Warning>
  Secret keys authorize spending your credits **and** retrieving stored biometric captures. Keep them in server-side environment variables only — never in client code, mobile builds, or version control.
</Warning>

## Session client tokens (`sst_…`)

Short-lived, single-use tokens for the [verification session](/verification-sessions/overview) capture flow. Your backend mints one by creating a session with its secret key, then hands **only the token** to the browser or app:

```bash theme={null}
Authorization: Bearer sst_...
```

A session token can do exactly two things: read its own session's metadata (`GET /v1/verification_sessions/session_info`) and submit a capture (`POST /v1/verification_sessions/submit`). It can never read a decision, a score, or stored media — so a token leaked from a client is not a path to anything sensitive.

## Credential comparison

|                                            | `sk_live_…` secret key | `sst_…` session token        |
| ------------------------------------------ | ---------------------- | ---------------------------- |
| Lives in                                   | Your server            | Browser / mobile app         |
| Lifetime                                   | Until revoked          | Session TTL (default 15 min) |
| Detection endpoints                        | ✅                      | ❌                            |
| Create sessions, read results, fetch media | ✅                      | ❌                            |
| Read own session metadata (`session_info`) | ✅                      | ✅                            |
| Submit a capture                           | ❌                      | ✅                            |