API key format#
All public API keys start with esi_dev_ followed by 43 URL-safe base64 characters of cryptographic randomness (51 characters total).
esi_dev_T2tFc3ZhZXNpRGV2QXBpS2V5RXhhbXBsZUZvcmxhaXNHcm91cF8The first 8 characters of the random part form the lookup prefix shown in the API portal (for example esi_dev_T2tFc3Zh). The full key is shown exactly once at creation time and only its Argon2id hash is stored.
Using your key#
Include it in the Authorization header:
Authorization: Bearer esi_dev_YOUR_KEYevaesi.dev creates the session used for rooms, keys, credit and spend limits. API calls from your code always use bearer keys, never cookies.Key management#
Key management runs on the API portal's signed session routes. Create and rotate operations require CSRF protection and a recent two-factor verification.
| Action | Endpoint | Method | Notes |
|---|---|---|---|
| Create key | /v1/auth/api-keys | POST | Returns the raw key once |
| List keys | /v1/auth/api-keys | GET | Returns summaries only, never raw keys |
| Rotate key | /v1/auth/api-keys/:id/rotate | POST | New key now; old key overlaps for 24 hours |
| Revoke key | /v1/auth/api-keys/:id | DELETE | Immediate revocation |
| Usage stats | /v1/auth/api-keys/:id/usage | GET | Historical totals for that key |
Every key belongs to one room, chosen when the key is created. A room may hold any number of keys, and they share the room's memory, files, storage and spend limit.
Key scopes#
Creation requests use the string scopes inference, platform, and full. The list endpoint exposes the stored bitmask as scope_bitmask.
| Scope | Bitmask | Access |
|---|---|---|
inference | 1 | Public inference routes such as /api/v1/responses |
platform | 2 | Platform-oriented API access where exposed |
full | 3 | Both inference and platform scopes |
Key rotation#
When you rotate a key, the server creates a new key immediately and schedules the old key for revocation after a 24-hour overlap window. The replacement inherits the existing scope and expiry policy.
Security#
- Keys are hashed at rest
- Keys are shown exactly once at creation time
- Any number of keys per room; revoke the ones you no longer use
- Set expiry dates where temporary access is appropriate
- Revoke compromised keys immediately
- Never embed keys in client-side code