# Manage API keys

Source: https://convergingthought.com/docs/product/keys

> Create one credential per workload, inspect its identity, and revoke it when no longer needed.



Open [API keys](/internalize/app/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 [#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](/docs/guides/multitenancy).

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 [#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 [#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 [#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](/docs/getting-started/authentication) for the HTTP boundary and [Access troubleshooting](/docs/troubleshooting/access) for common key failures.