API keys are environment slots, not identities

API keys sound simple until they end up in the wrong place. A project key is not a user identity, not a browser credential, and not a magic replacement for authorization. In ZKAuth it is a server credential for one project environment: the thing your backend uses to talk to the engine.

ZKAUTH_API_KEY=zka_test_********************************ZKAUTH_API_URL=https://api.zkauth.dev

The dashboard copy uses key slots on purpose. A real project normally needs a test key and a live key. Those are two environment slots for the same project, not two developers, two applications, or two billing accounts. The distinction matters because it keeps the limits readable: projects limit product surfaces, key slots limit server credentials, and users limit end-user activity.

What a project key can do

• Authenticate server-side requests to the engine for a specific project.
• Separate test and live traffic without asking developers to reuse production secrets locally.
• Carry lifecycle metadata such as creation time, last use, rate-limit/quota state, and revocation status.
• Be rotated or revoked without changing the user's password or proof material.

A project key should never be bundled into a browser app. Browser flows should go through hosted pages, a framework integration, or an app-owned proxy route. If a key can be viewed in DevTools, it is in the wrong place.

Reveal once, operate by metadata

ZKAuth shows raw project key material only after generation or rotation. After that, the dashboard becomes an inventory surface: name, environment, status, last use, usage, quota, and actions. That is intentionally less convenient than showing the secret forever, but much easier to defend.

Boring key management is good key management. The goal is not to make secrets interesting; it is to make the safe path obvious enough that nobody has to improvise.