[nofuturekid]

What changed

• README.md: new section "API key permissions" (anchor #api-key-permissions). It says in plain words which key NOVA needs: VIEWER for read-only, ADMIN for everything, or VIEWER plus only the wanted UPDATE_ANY / DELETE_ANY permissions for least privilege. A table lists the resource and action per feature and marks each row as Live (run against a real server, Unraid 7.4.0 / API 4.37.11) or Source (read from the Unraid API source at 4.37.11, not tried with a key that holds only that permission), with footnotes. It also covers where the key and its permissions are set, what the server answers when a permission is missing ("Forbidden resource"; a later version will hide controls the key cannot use, no date given), and the API versions (4.30.0 for every screen, 4.35.0 for network speed; API versions, not Unraid OS versions). Step 2 of Getting started links to it.
• site/index.html: a short "Which API key" part in the setup section, with the same three choices, linking to the README table. It uses the existing classes, so light and dark themes are unchanged and nothing new is loaded.

Why

Users should be able to create a least-privilege key instead of an ADMIN key (#316).

Deliberately left out

• No app code, app strings or Add server sheet changes (a later PR).
• No ADR, no CHANGELOG line (the rules ask for entries for user-facing behaviour changes, not for documentation).
• docs/privacy/POLICY.md: its statements about the API key are still correct.
• Not verified, and said so in the text: a key with only explicit permissions (it needs keys created on a server), what the API settings page shows for the version. The command-line example: the command shape with the VIEWER role and DOCKER:UPDATE_ANY was run live, the other permissions in the example were not tried.

Checks

Docs-only; no Gradle, docker or local-ci. Changed paths do not match the build-affecting filter in ci.yml. External links return 200. The added HTML is balanced.

Live results (2026-11-13, Unraid 7.4.0, API 4.37.11, temporary key deleted afterwards)

• Verified live: a key with only the VIEWER role got HTTP 200 with data on every screen's query, and the logs query was checked only as far as the permission (sent with an unknown container id); container start, stop, restart (stop then start), pause, unpause and update of one container need DOCKER:UPDATE_ANY (refused without it, accepted past the permission check with it); me reports the role plus the explicit permissions.
• Refusal only: VM actions (VMS:UPDATE_ANY), archive and mark notifications (NOTIFICATIONS:UPDATE_ANY), delete notifications (NOTIFICATIONS:DELETE_ANY): a key without the permission is refused; sufficiency is from the source.
• Source only: array start/stop and parity check (ARRAY:UPDATE_ANY), update all containers (not testable without acting on a server).
• Correction: a key with permissions and no role could not be created with the server's command line tool (a role is required); the docs now say "VIEWER plus the explicit permissions".

Refs #316 (stays open: the Add server sheet link comes with a later pull request; rows verified only from source are marked as such)

🤖 Generated with Claude Code