Authentication
API keys, what they allow and how they stop working.
The header
Every request carries your key as a bearer token. Keys are sk-so-v1- followed by 64 hex characters.
1Authorization: Bearer sk-so-v1-...A key is shown once, when you create it. We store only its SHA-256, so we cannot show it to you again and neither can anyone who reaches our database — a lost key is replaced, not recovered.
When a key stops working
| Reason | Response |
|---|---|
| You disabled it | 401 key_disabled |
| It passed its expiry date | 401 key_expired |
| Its spend reached the key's credit limit | 402 key_limit_reached |
| The account ran out of credits | 402 insufficient_credits |
| It sent more requests than its per-minute allowance | 429 rate_limit_exceeded |
Disabling a key keeps its history, so its past usage stays visible in Logs. Deleting one removes the key but leaves the usage rows behind.
Key kinds
Inference keys call models. Management keys are meant for administering the account and are refused here with 403 wrong_key_kind — the management API itself is not built yet, so for now a management key cannot do anything.
Calling from a browser
The API sets permissive CORS headers, so a browser can call https://api.sothe.net/v1 directly. That is useful for a prototype and dangerous in production: anything the browser can read, your users can read, including the key.
Put a small endpoint of your own in front of Sothe and keep the key there. Then a leaked browser session costs you one user's requests rather than your whole balance.