API keys are how your applications authenticate to ManyLayers. Every key belongs to a team and inherits that team’s model allow-list and limits. You can stack additional per-key limits on top — for example, a key used by a specific microservice might have a tighter RPM limit than the team’s overall budget allows. Keys are prefixed with ml- so they’re easy to identify in logs and code reviews.

​
Creating a key

From the workspace UI: go to Settings → API Keys → New key. Choose the team, set optional per-key limits, and optionally set an expiry date. Via the API: 
curl -X POST http://localhost:8180/admin/keys \
  -H "Authorization: Bearer $ADMIN_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "prod-api",
    "team_id": "engineering",
    "rpm_limit": 200,
    "tpm_limit": 100000,
    "budget_usd": 50,
    "expires_at": "2025-12-31T00:00:00Z"
  }'
The response includes the full key value — store it securely. ManyLayers stores only a hash; the plaintext key cannot be retrieved after creation.

​
Per-key limits

Per-key limits stack on top of team limits. A request is rejected if it would exceed either the key-level or team-level limit.
LimitDescription
rpm_limitMaximum requests per minute from this key
tpm_limitMaximum tokens per minute from this key
budget_usdLifetime USD spending cap for this key
expires_atHard expiry date — key stops working after this timestamp
Setting expires_at is useful for giving external contractors or integration partners time-bounded access. The key automatically stops working at the configured time without requiring manual revocation.

​
Giving different applications different access levels

A common pattern is to create one key per application or service:
  • Prod key — full RPM limit, moderate USD budget, 90-day expiry
  • Staging key — lower RPM limit, small USD budget, no expiry
  • CI key — very low RPM limit, tiny USD budget, no expiry
  • Partner key — scoped to a specific model, hard expiry date
Each key is visible in the audit log, so you can always see which application made which request.

​
Rotating keys

When you need to rotate a key (for example, after a potential exposure):
  1. Create a new key with the same team and limits.
  2. Update your application to use the new key.
  3. Delete or expire the old key.
# Delete an old key
curl -X DELETE http://localhost:8180/admin/keys/$KEY_ID \
  -H "Authorization: Bearer $ADMIN_KEY"
There is no grace period — deleted keys are rejected immediately. Plan your rotation to avoid downtime.

​
Personal Access Tokens

In addition to service API keys, workspace users can create Personal Access Tokens (PATs) for their own API access. PATs are prefixed with ml_pat_ and are scoped to the user’s team membership.

​
Next steps

  • Organize keys into teams with shared limits
  • Set up SSO & SCIM to automate user provisioning
  • Monitor key usage in audit logs