Manage API keys
Create one credential per workload, inspect its identity, and revoke it when no longer needed.
Open API keys in the intended project. Keys are server credentials, so create them for the application or worker that will call Internalize rather than for individual browser tabs.
Create
Select Create API key, enter a recognizable name, and choose permissions. The dialog defaults to Inference only, including access to its own request results. Inference + learning explicitly adds learning and activation of the resulting candidate. Management only is under Advanced and requires a separate acknowledgement; it can inspect project activity and activate retained versions but cannot run inference or train. Existing keys keep their current scopes. Restrict to a customer optionally binds the key to one tenant_id without changing its permissions. Leave it blank when your server serves multiple customers and selects an authorized tenant on each request. The restriction cannot be edited later; rotate the key to change it. See Serve multiple customers.
Select an expiry that fits your rotation process. The console offers 30 days, 90 days, one year, and no expiration. Avoid choosing an expiry shorter than your ability to update the deployment that will use the credential.
After creation, copy the full secret once and save it in the destination server's secret store. The success dialog is the only point at which the full key is available. Closing it does not save the secret into your application automatically.
Identify and inspect
Use the key's name, prefix, scope set, and expiry to identify it later. The prefix is a label, not a usable credential. Last-used information is updated by admitted model work; do not treat it as a comprehensive log of every successful read request.
The platform caps projects at 50 non-revoked keys. Expired but non-revoked keys still count toward that limit. Revoke retired records as part of routine credential cleanup.
Rotate
Create the replacement first. Update your authorized server configuration and verify a read such as /v1/models, then verify the relevant scoped operation when execution is enabled. Revoke the old key after the application has moved over.
If a key is lost before it is saved, create a replacement and revoke the inaccessible one. The platform cannot reveal the original secret from its stored hash. If a key is exposed, revoke it promptly and inspect Activity for unfamiliar work.
What revocation changes
Revocation stops later requests authenticated with that credential. It does not cancel existing jobs, remove adapters, reset subjects, or reverse settled charges. A different valid key for the same project can continue reading jobs if it has read permission.
There is no public key-management REST endpoint in this release. Use the console rather than automating against private session routes. See Authentication for the HTTP boundary and Access troubleshooting for common key failures.