Issue API keys and access policies

General Settings holds the controls that decide what everybody else can reach — permissions, access policies, and the keys other systems authenticate with.

Define an access policy first

An access policy is a named bundle of permissions and scopes, created under Access Policies. Give it a name that describes a job rather than a person — Operations Manager ages better than someone’s name.

Policies are what API keys attach to, so a policy that is too broad turns into a key that is too powerful. Build the narrow one you need rather than reusing a wide one that happens to work.

Create an API key

Under API Keys, use + Create API Key. A key needs a Name, a User to act as, at least one access policy, and optionally an expiry date. The key acts with the reach of the policies you attach — nothing wider.

Issue one key per integration. Sharing a single key across systems means revoking access to one of them forces you to rotate all of them.

Revoking

Active keys carry a Revoke action, confirmed and permanent. Expiry is computed from the date you set, so a key with no expiry stays valid until revoked by hand — worth setting one for anything temporary.

Permissions and roles

Permissions maps permission keys against roles. Permissions gate what appears, not merely what is clickable, so a colleague reporting a missing screen is usually reporting a permission rather than a fault. Check their role before investigating further.

The API key secret is shown exactly once, in the dialog that appears right after you create it, and closing that dialog clears it permanently — the table only ever shows the key’s prefix. Copy it into your password manager before you press Done. If you lose it, there is no recovery: revoke the key and issue a new one.