Authentication

API key format

API keys follow the format cue_sk_ + 32 hex characters:

cue_sk_a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4

Storage

CueAPI never stores API keys in plaintext. When a key is created:

1. The plaintext key is shown to the user once
2. A SHA-256 hash is computed and stored in the database
3. A 4-character prefix is stored for display purposes (cue_sk_a1b2...)
4. The plaintext key is discarded

Authentication flow

Request → Extract Bearer token
       → SHA-256 hash the token
       → Check Redis cache (auth:{hash}, 5-min TTL)
       → On cache hit: return cached user
       → On cache miss: query PostgreSQL
       → On DB match: cache result, return user
       → On no match: 401 Unauthorized

Redis caching

Authenticated users are cached in Redis for 5 minutes to reduce database queries:

• Key: auth:{sha256_hash}
• Value: JSON user object (id, email, plan, limits)
• TTL: 300 seconds

If Redis is unavailable, CueAPI falls back to PostgreSQL directly. Auth never fails due to Redis being down.

Key rotation

When you regenerate your API key:

1. A new key is generated with a new hash
2. The old hash is removed from Redis cache
3. The new hash is cached in Redis
4. The old key immediately stops working

There is no grace period. The old key is revoked instantly.

Best practices