Scoped API keys — restrict a key to specific site keys and permission levels

Hello everybody

I just started to use Cap and like it a lot, but I have some ideas for for improvements.

Problem:

Currently, API keys created under Settings → API Keys have unrestricted access to all site keys on the instance. This makes API keys unusable in any multi-tenant setup where different site keys belong to different customers/projects and shouldn't be able to see or manage each other's data.

Concretely: I run one Cap Standalone instance serving multiple client websites, each with its own site key. Integration happens through a custom WordPress plugin we built in-house, which already handles per-client site key/secret configuration, widget embedding, and server-side /siteverify calls for each client's forms (Elementor, WP login/registration/lost-password, comments, WooCommerce). The natural next step would be a small read-only "stats" panel inside each client's own WordPress admin, showing only their own site key's solve statistics — but right now the only way to fetch that server-side is with an API key that can read every site key's data. That means every client's plugin instance would effectively hold a master credential, even though it should only ever see its own numbers.

Proposed feature:

When creating or editing an API key, allow scoping it to:

Specific site keys — an allow-list of one or more site keys the API key is permitted to access. Omitting this (or an explicit "all") would keep today's behavior for backward compatibility. Permission level — at minimum a read-only flag (stats/session/key info only, no create/update/delete/rotate-secret). (nice to have) Endpoint-level restriction — e.g. a key that can only call the stats endpoints, not the key-management endpoints, independent of the read-only flag. Example use case Agency/reseller runs one Cap instance for many client sites, integrated through a shared WordPress plugin. For each client, an API key is created scoped to only that client's site key, read-only — safely embeddable in that client's own WordPress plugin instance to power a self-service stats view. Why this matters

Without scoping, API keys can't be handed out or embedded anywhere outside the instance operator's own trusted backend — which limits Cap's usefulness for agencies/hosters managing many independent site keys on shared infrastructure.

Happy to test this against a real multi-tenant setup if it'd help validate the design.