API keys
API keys let your own systems call the Peki API: your app's chat screen, your CRM or a script on your server. Each key belongs to one workspace and has an access level. You manage keys in Settings → API keys.
API keys are for calling Peki. Keys that your agent's tools use to call your APIs are different: they live in Settings → Secrets. See Variables and secrets.
Who can manage keys
Only admins and owners can see, create and revoke API keys. Other members see "Only admins can change workspace settings."
Create a key
- Go to Settings → API keys.
- Give the key a name that says where it's used, for example "Mobile app" or "CRM sync". Up to 80 characters.
- Choose the Access: Read only or Read and write.
- Click Create key.
- Copy the key from the green box. Peki says: "Copy this key now — it won't be shown again."
The key looks like this:
psk_3QeR8v…
Every key starts with psk_. Peki stores only a fingerprint of it, so nobody, including us, can show it to you again. If you lose it, create a new key and revoke the old one.
Access levels
| Access | Acts as | Can |
|---|---|---|
| Read only | Viewer | Read data: list and read sessions and their messages, download files. |
| Read and write | Editor | Everything read keys can, plus start sessions, send messages, upload files, rename, rate and resolve sessions. |
A key never acts as an admin or owner, whatever its access. So no key can:
- invite, change or remove members,
- create or revoke API keys,
- delete agents or the workspace,
- decide approvals, which are for people only.
Give each key the least access it needs. A dashboard that only shows conversations needs Read only. Your app's chat screen needs Read and write.
Use a key
Send it in the Authorization header as a bearer token:
curl https://peki.ai/api/agents/AGENT_ID/sessions \
-H "Authorization: Bearer psk_your_key"
The key already says which workspace it belongs to, so you don't need to send a workspace header. See Authentication for the details and errors.
The keys list
Each key in the list shows:
| Field | Example | Meaning |
|---|---|---|
| Name | CRM sync | The name you gave it. |
| Prefix and last four | psk_3QeR8vXy…a1B2 | The first 12 and last 4 characters, so you can tell keys apart. |
| Access | Read and write | The access level. |
| Last used | used 5 minutes ago | When a request last used it, or never used. |
Use Last used to find keys you can remove: a key that says never used weeks after you created it is probably not needed.
Revoke a key
- Click Revoke next to the key.
- Confirm. Peki warns: "Anything using this key stops working at once."
A revoked key is refused from the next request (401 Invalid API key). You can't undo a revoke; create a new key instead.
Rotate a key
To replace a key without downtime:
- Create a new key with the same access.
- Put the new key in your system and deploy.
- Check the old key's Last used stops changing.
- Revoke the old key.
Keep keys safe
- Keep keys on your server. Never put an API key in a website's JavaScript, a mobile app bundle or anything a customer can download. Anyone who has the key can act as your workspace. Call Peki from your backend, and let your app talk to your backend.
- Store them as secrets. Use your hosting's secret store or environment settings, not your source code. Don't commit keys to git.
- One key per system. Separate keys for your app, your CRM and your scripts mean you can revoke one without breaking the others, and Last used tells you which system is active.
- Revoke when people leave. If someone who had a key leaves, rotate it.
- Revoke on any doubt. If a key may have leaked, revoke it right away and create a new one.
Treat a key like a password. Don't paste it into tickets, screenshots or chat messages.
Audit
Creating and revoking keys is written to the workspace's audit log, with who did it. Changes a key makes are recorded as made by that key. See Security model.