API key lifecycle

API keys belong to an account, not to a project. Use the same key with every project the account may access. Key-management endpoints use the normal account authentication dependency, so either a Logto dashboard session or an active account API key can call them. Treat a key as an account credential, not as a project-limited token.

Endpoints

GET    /api/v1/keys
POST   /api/v1/keys
PATCH  /api/v1/keys/{key_id}/activate
PATCH  /api/v1/keys/{key_id}/deactivate
DELETE /api/v1/keys/{key_id}

Create a key with an optional display name:

POST /api/v1/keys
Content-Type: application/json

{"name": "production ingestion"}

The 201 response is the only response that contains key, whose value starts with fnf_. Copy it immediately. ReOpenly stores only a digest plus a masked prefix and last four characters, so it cannot recover the key later.

Listing safely

GET /api/v1/keys always returns a bounded cursor page (25 rows by default). No pagination mode is required; cursors belong to your account:

GET /api/v1/keys?limit=25
GET /api/v1/keys?limit=25&cursor=<next_cursor>

The cursor response is {data, next_cursor, total_count}; the maximum limit is 100. List rows contain id, name, masked_key, active, created_at, and last_used_at. They never contain a working credential.

Deactivation is reversible and immediately stops authentication. Activation restores the same key. Deletion is permanent; create a replacement before deleting a key used by a live integration.