# POST /v1/api-keys/:keyId/kill (/docs/api/reference/api-keys/kill)



<Endpoint method="POST" path="/v1/api-keys/{keyId}/kill" auth="X-Api-Key" phase="1" />

**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.

<Parameters
  title="Path"
  rows="[
  { name: 'keyId', type: 'string (UUID)', required: true, description: 'The api_keys.id of the key to kill. Must belong to the same org as the calling key.' },
]"
/>

<Parameters
  title="Headers"
  rows="[
  { name: 'Idempotency-Key', type: 'string (UUID)', description: 'Replays within 24h return the same result — killing an already-killed key is a no-op, not an error.' },
]"
/>

## Example [#example]

```bash
# 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)"
```

<Response status="200" description="OK — key killed">
  ```json
  {
    "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
  }
  ```
</Response>

## What happens next [#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 [#errors]

| Status | Code                   | When                                                                                                     |
| ------ | ---------------------- | -------------------------------------------------------------------------------------------------------- |
| 404    | `NOT_FOUND`            | Key ID doesn't exist, or belongs to a different org. Deliberately ambiguous to avoid tenant enumeration. |
| 409    | `IDEMPOTENCY_CONFLICT` | Idempotency-Key reused with a different body.                                                            |
| 422    | `VALIDATION`           | Missing `:keyId`.                                                                                        |

## See also [#see-also]

* [Authentication — kill switch](/docs/api/getting-started/authentication#kill-switch)
* [API keys concept](/docs/api/concepts/api-keys)
* [Security & compliance](/docs/api/operational/security-and-compliance)