Gateway credentials are platform administration. The dashboard is the Platform Super Admin’s
surface; a Customer Admin manages their own organisation’s MITHUNAI API
keys instead, which are a different credential for a different surface.
1. Provider credentials — the keys the Gateway spends
These are your upstream accounts: the credentials the Gateway presents to a model provider. They are stored encrypted, never returned in full after they are entered, and never logged. Each credential carries:- A health state. A background probe marks a credential healthy or invalid, and an unprobed credential counts as usable until a probe says otherwise. An invalid credential stops being chosen.
- An optional model scope. A credential can be restricted to a named list of model ids — some resellers issue keys that only serve one model group. A scoped credential is never chosen for a model outside its list, and is not counted as a usable sibling for one either. No scope means it serves every model of its provider.
- Optional monthly caps. Two independent caps, requests and tokens, each counted against the current UTC month’s successful requests.
0means unlimited, which is the default. - An observed quota, where the provider reports one. Remaining, limit and reset time are recorded per credential and pooled per provider — see the model catalogue.
What a cap does when it is reached
A request against a capped-out credential is refused withquota_exceeded and a 429, carrying a Retry-After of the seconds remaining until the next UTC month. That is deliberate: an agent that is told when the window resets stops hammering, where a bare 429 invites a retry loop.
In-flight requests reserve their estimated tokens until they finish, and the real provider usage is settled from the request log afterwards. The estimate is an admission guard, not an exact billing cap — it keeps a single large request from blowing through a cap that was already nearly spent, and it is not a substitute for the provider’s own accounting.
What these caps are not
They are counted in requests and tokens, not currency. The Gateway holds no price you agreed with a provider and issues no invoice, so it cannot enforce a dollar ceiling; the nearest honest equivalent is a token cap together with the paid-equivalent estimate described in the model catalogue. There is also no notification webhook on an approaching cap, and no IP allowlist on a key — if you need either, say so, and see Product status for how planned work is tracked.2. The inbound key — how a client reaches the Gateway
One key authenticates application traffic to the Gateway’s/v1 surface. It is read and rotated from the dashboard:
Authorization: Bearer, x-api-key, or x-goog-api-key for Gemini-shaped clients — which is what lets an unmodified OpenAI, Anthropic or Gemini client point at the Gateway and work.
Rotating it invalidates the previous value, so roll it out to your callers in the same change.
3. Client-profile keys — one key per calling application
A client profile is a separate key, prefixedsk-cp-, issued per calling application. Beyond identifying the caller it carries an optional system prompt that is injected into the requests made with it, which is how one deployment serves several tools with different standing instructions through the same Gateway without each tool shipping its own prompt.
- The full secret is returned exactly once, from creation and from rotation. Afterwards the dashboard shows only a masked form.
- Authentication stores nothing but a SHA-256 digest of the key, so the database holds no plaintext for the auth path, and the indexed lookup does not depend on the secret’s bytes.
- A profile can be disabled without being deleted, and rotated without being recreated.
- Clearing the system prompt leaves the key working and injecting nothing.
/api/client-profiles: list, create, update, rotate and delete.
Revocable URL tokens
For a client that can only be given a URL and no header, the Gateway can mint a token that lives in the path —/v1/t/<token>/… — and be revoked individually without rotating the inbound key. Tokens are managed from the dashboard’s settings surface. A URL carries further than a header does, into browser history and proxy logs, so treat a URL token as the more exposed credential of the two and revoke it when the client that needed it is gone.
Rate limiting
The/v1 surface and the /api dashboard surface each carry their own request-rate limiter, configured per deployment. Those are separate from the monthly caps above: a limiter bounds how fast a caller may ask, a cap bounds how much a credential may spend in a month.