# API keys

Manage keys in the console under **API keys**, or with the API.

| | |
|---|---|
| GET `/v1/api_keys` | List keys (never their secrets) |
| POST `/v1/api_keys` | Create a key; returns its secret once |
| PATCH `/v1/api_keys/{key_id}` | Rename, deactivate or reactivate |
| POST `/v1/api_keys/{key_id}/rotate` | Replace the secret; returns the new one once |
| DELETE `/v1/api_keys/{key_id}` | Revoke for good |

`{key_id}` is the key's `id` (a UUID) from the list, not its public `your_key_id` key ID.

```json
{
  "api_key": { "id": "9b2e…", "key": "7Hx2Qp9LmZ", "name": "Production", "status": "active", "has_secret": true, "created_at": "2026-09-27T10:00:00Z" },
  "key": "7Hx2Qp9LmZ",
  "secret": "your_secret",
  "note": "Save this secret now — it is not shown again."
}
```

## Practices

- **One key per integration or environment**, named so you can tell them
  apart. `last_used_at` shows which are in use.
- **Keep secrets server-side.** Never ship a secret in a browser or mobile app;
  anyone who has it can call the API as you.
- **Rotate on a schedule and on suspicion.** Rotation keeps the key ID, so only
  the secret changes in your configuration. The old secret stops working
  immediately, so deploy the new one first.
- **Deactivate before deleting** if you are unsure a key is unused: a
  deactivated key fails with `401` and can be reactivated.

Every console user of the account gets an email when a key is created,
rotated or revoked.

## Legacy keys

Keys created before request signing are marked `legacy` and have no signing
secret (`has_secret: false`). Rotate them to get one; see
[Authentication](https://sigwise.ai/docs/guide/authentication.md#deprecated-legacy-keys).
