Virtual Keys

1. Validates the virtual key
2. Loads the key’s budget and rate limits, plus the tenant’s policies
3. Swaps in the real provider credential before forwarding the request

​

Why virtual keys?

​

Key properties

• Monthly budget — hard spend ceiling in USD (enforced via Redis before forwarding)
• RPM limit — requests per minute cap
• TPM limit — tokens per minute cap
• Key class — interactive (developer) or ci (headless), set at creation; CI keys get their own budget pool
• Owner — the user the key is attributed to in analytics
• Team (cost center) — which team the key’s spend bills to on the LEDGER. Independent of owner: defaults to the owner’s team at creation, but is overridable — so a key can be owned by one person and billed to another team (cross-charge), or have a team with no human owner at all (CI/service keys)

​

Creating a key

​

Console

​

REST API

curl -X POST https://api.wardin.ai/v1/keys \
  -H "Authorization: Bearer wardin_sk_ADMIN_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "label": "alice-dev",
    "keyClass": "interactive",
    "budgetUsd": 50,
    "rpmLimit": 60,
    "tpmLimit": 100000
  }'

{
  "id": "550e8400-e29b-41d4-a716-446655440000",
  "label": "alice-dev",
  "keyClass": "interactive",
  "rawKey": "wardin_sk_abc123...",
  "rpmLimit": 60,
  "tpmLimit": 100000,
  "ownerId": null,
  "ownerEmail": null,
  "teamId": null,
  "teamName": null,
  "revokedAt": null,
  "createdAt": "2026-01-15T10:00:00Z"
}

​

Key lifecycle

active → paused → active   (manual toggle)
active → budget_exceeded   (automatic, resets monthly)
active → revoked           (permanent)

{
  "error": {
    "type": "budget_exceeded",
    "message": "Monthly budget of $50.00 has been reached.",
    "code": 429
  }
}

​

Security recommendations

• Issue separate keys for each developer and each CI environment
• Set conservative budgets; raise them via budget increase requests
• Register wardin_sk_ with your secret scanner (GitHub Advanced Security, truffleHog, etc.)
• Rotate keys periodically — revoke the old one, issue a new one
• Never commit virtual keys to version control