Managing read-only API keys

API keys give you programmatic, read-only access to your workspace's data: pending and resolved corrections, repo check status, token usage, and the list of documentation pages Amendary watches. Use a key to pull this information into your own dashboards, alerting tools, or scripts, without signing in to the dashboard.

You need the owner role to create or revoke a key. Any workspace member can see that keys exist, but only an owner manages them.

What a key can do

An API key is strictly read-only. It cannot create, approve, reject, or revert corrections, and it cannot change any workspace setting. It always acts within the single workspace it was created in.

<aside> ✏ A key does not spend workspace resources. Reading usage or corrections through the API doesn't count against your generation credits, and it works even if daily automated checks are paused (for example, during a suspended trial or a lapsed subscription). Revoking the key is how you cut off a workspace's access once it's no longer needed.

</aside>

Create a key

Go to Settings and open API keys.
Select Create key.
Enter a name that identifies where the key will be used, and save it.

Result: the raw key is shown once, immediately after creation. Copy it into your integration now, because it is never shown again. The keys list afterward shows only the name, a short prefix, and when the key was created or last used, never the full key or its hash.

<aside> ⚠ If you lose a key after this screen closes, there's no way to retrieve it. Revoke the old key and create a new one instead.

</aside>

View existing keys

Open Settings > API keys to see every key on the workspace: its name, creation date, and last-used time. This list is the same for every member, regardless of who originally created a given key, since access is scoped to the workspace rather than to an individual person.

Revoke a key

Open Settings > API keys.
Find the key you want to remove and select Revoke.

Result: the key stops working immediately. Any request made with it afterward is rejected the same way an unknown or malformed key would be, so a revoked key gives no hint to whoever is holding it about why it stopped working.

<aside> ✏ Creating and revoking a key are both recorded in your workspace's activity history. Reads made with a key are not logged individually, so a tool polling the API on a schedule won't fill up your activity feed.

</aside>