Give each integration its own key.

Define scopes before creation

Give a key only the actions and resources its job requires. A monitoring integration may need read access; a deployment tool may need a defined set of lifecycle operations. Keep billing authority separate where possible.

Reveal carefully and store privately

A real key should be shown through a secure creation flow, protected at rest and excluded from URLs, browser bundles and source control. Record the owner, purpose and creation time without exposing the secret itself.

Make revocation practical

Issue separate credentials per integration so one can be revoked without stopping everything. Rotate deliberately and verify that the old key no longer works. Investigate unexpected usage with bounded audit records.

Test the limits

A useful launch test includes an allowed operation, a forbidden operation, an expired or revoked key and a request outside the key’s resource boundary. Authentication alone is not authorisation.

Candidate key policy

The API contract describes up to ten active keys per account, with named purposes, optional expiry and source-address restrictions. Scopes separate read, server management, billing and full control. A creation flow should show the secret once and retain only an appropriately protected verification representation.

Audit without exposing the request

A useful audit record can include key identifier, route, time and outcome without retaining passwords or entire request bodies. Access to the record still needs protection. Define retention and export rather than keeping sensitive operational history indefinitely.

Give each automation its own credential

A backup checker, deployment worker and billing integration should not share the same full-access key. Name a key for its job, grant the smallest scope and record who owns it. The intended groups are read, servers, billing and full; their exact operation mapping must be tested when the API becomes available.

Creation, storage and rotation

The proposed account model allows up to ten active keys. Show a new secret once, then retain only the server-side verifier needed to authenticate it. Store the client copy in a secret manager or protected service environment. Rotate by introducing a replacement, checking the dependent worker, then revoking the old key; never place a key in a public URL or browser bundle.

Revoke the access, not the evidence

Disabling a key should stop future requests while preserving a limited security record of its past use. If a credential may have leaked, revoke it promptly, examine affected resources and replace any related secrets. A key list should show a safe identifier and last-use metadata rather than recoverable plaintext secrets.

A little more clarity.