API Keys
What is an API key?
Section titled “What is an API key?”An API key is a randomly generated string that your application sends with every request to maKI. From the key, maKI knows who is asking and which models may be called; usage is logged per key.
You need a key as soon as you call maKI from your own code, an SDK, a notebook, or a tool like curl — anything outside the admin UI at /ui/.
Treat the key like a password:
- Never check it into source code or a Git repository
- Store it in an environment variable, a secret manager, or 1Password
- If you suspect it has been compromised, request a revocation immediately
Key types
Section titled “Key types”| Type | Assignment | Personal reference | Example |
|---|---|---|---|
| Personal key | Individual person | Yes (indirectly via usage data) | Philipp Hematty |
| Service key | Application or team (≥3 persons) | No | F13-Assistenzsystem |
| Batch key | Ad-hoc bulk processing | No | embedding-migration-2026 |
Requesting a key
Section titled “Requesting a key”Contact the maKI administrator (philipp.hematty@uni-mannheim.de) with:
- Name of the service or team
- Contact person (technical contact)
- Intended use (brief description)
Revoking a key
Section titled “Revoking a key”If a key is suspected to be compromised:
- Report immediately to philipp.hematty@uni-mannheim.de
- Administrator disables the key via the LiteLLM admin UI (
/ui) - New key is issued and communicated to the contact person
- Old key is permanently deleted
Revoked keys become invalid immediately — in-flight requests are completed, new requests are rejected.
Prioritization
Section titled “Prioritization”API keys are prioritized by type under GPU load:
| Key type | Priority | Behavior under load |
|---|---|---|
| Personal | High (1) | Requests are served first from the queue |
| Service | Normal (64) | Requests wait behind personal requests |
| Batch | Low (128) | Requests wait behind personal and service requests |
When the GPU is not saturated, all key types get full throughput — there is no artificial throttling. Prioritization only kicks in when all parallel slots for a model are occupied.
Limits
Section titled “Limits”Concurrency
Section titled “Concurrency”A model may have a limit on concurrent requests (max_parallel_requests); the table shows the current state. Excess requests are queued and served by priority. If the queue is long, requests receive HTTP 429 and should be retried with exponential backoff.
Loading model list …
Request size
Section titled “Request size”There is currently no hard token limit per request. The models’ context windows apply:
Loading model list …
Budget
Section titled “Budget”With exclusively local models, there are no per-key cost budgets. Usage is tracked for planning purposes (timestamp, model, token count).
Monitoring
Section titled “Monitoring”Usage is tracked per key:
- Requests per model and time period
- Token consumption (input/output)
- Error rates
This data is used for capacity planning and cost allocation, not behavioral monitoring (see Privacy Policy).