POST /v1/api-keys/:keyId/kill

Emergency stop. Flips kill_switch=true + sets is_active=false + stamps revoked_at on the key. The killed key starts returning 503 KILL_SWITCH on the next request regardless of which code path reads the row first.

Designed for the leaked-key path: any partner key on your org can kill any other key on your org without an admin seat. You don't need to page a human — fire this endpoint the moment you suspect a leak.

Killed keys can be un-killed only via the admin console (recovery requires human verification). The partner surface is write-only for safety.

Example

# Leaked key emergency response
curl -X POST https://api.layers.com/v1/api-keys/c2037bb9-354d-4662-96b7-97a28ad6b6e1/kill \
  -H "X-Api-Key: $LAYERS_API_KEY" \
  -H "Idempotency-Key: $(uuidgen)"

{
  "apiKey": {
    "id": "c2037bb9-354d-4662-96b7-97a28ad6b6e1",
    "organizationId": "2481fa5c-a404-44ed-a561-565392499abc",
    "name": "production-service",
    "prefix": "lp_live_01HXA1NHKJZXPV8RAB",
    "killSwitch": true,
    "isActive": false,
    "revokedAt": "2026-04-20T18:14:02.187Z"
  },
  "killed": true
}

What happens next

1. Every in-flight request on the killed key completes (mid-flight requests aren't aborted mid-response).
2. Every subsequent request on the killed key returns 503 KILL_SWITCH with details.scope: "key". Each partner request hits a fresh DB lookup (no verify cache), so propagation is effectively immediate.
3. Re-enable the key: admin-only via the Layers admin console. Self-serve un-kill is deliberately not exposed — recovery requires human verification that the leak is contained.
4. If the kill is part of a planned replacement (rather than pure quarantine), mint the new key first in the Layers dashboard, deploy it to your services, then kill the old one. Partner-API key issuance is dashboard/admin-only — there is no partner endpoint for POST /v1/api-keys.

Errors

See also

• Authentication — kill switch
• API keys concept
• Security & compliance