API keys and identity binding
Create a scoped runtime credential and manage its binding and revocation.
On this page
Choose an environment
Open Connections → API keys in the console and select the intended environment. An administrator can create a named key, set available expiry options, and configure a supported identity binding. Record its purpose and owner before giving it to a server application.
Copy the newly issued secret into your server’s secret store. Subsequent listing and account-connector output show key metadata, not a recoverable plaintext credential. Do not place the key in browser JavaScript, a repository, or a public example.
Bind a trusted scope
The backend supports customer, principal, and agent bindings. An agent binding must refer to a valid agent with compatible principal information. Inspect the resulting binding before relying on it for authorization or usage attribution. A display label and an independently authenticated identity are different things.
Agent inventory · Policy attributes
Verify a key
Use a harmless evaluation in the selected environment and confirm the result and recorded scope. Test the intended binding using the actual integration. An API key authenticates runtime access; it is not a human approver.
Rotate or revoke
To rotate operationally, create a replacement, update the authorized server, verify it, then revoke the retired key. Revocation is an administrator action. Test the expected authentication failure without bypassing policy using a provider key directly.
Customer management routes live under /api/v1/api-keys; creation, binding changes, and revocation require administrator authority. Runtime usage follows authentication.