RenewCMS/docs/api/api-keys.md

API keys

Developers can authenticate against /v1 with a named API key sent as Authorization: Bearer rcms_... instead of the jwt cookie. A key acts with exactly the rights of the user who created it.

Managing keys

Key management needs a real session (the jwt cookie from a verified user).

• POST /v1/api-key with {"name": "ci", "expires_at": "<RFC3339, optional>"} answers 201 with id, name, prefix, key, created_at, expires_at. The full key is shown once and never again.
• GET /v1/api-key lists the caller's keys (all keys for the owner), newest first, with a status of active, expired or revoked.
• DELETE /v1/api-key/{id} revokes a key and answers 204. Revoking twice keeps the first revoked_at.

Only the SHA-256 hash and a 12 character prefix are stored.

Where a key is accepted

/v1/article (public and protected routes), /v1/user, /v1/media, /v1/settings and GET /v1/auth/me. An invalid, expired or revoked rcms_ key answers 401 and is never treated as anonymous. Each key is limited to 120 requests per minute (429 with Retry-After). last_used_at is updated at most once per minute.

Session-only routes

/v1/api-key, POST /v1/auth/verify, DELETE /v1/auth/register and every /v1/system route answer 403 This action needs a real session. to any rcms_ Bearer header. The public auth routes ignore the header.

A successful password reset revokes every key of that user.