API keys
Format
ppk_live_<64 hex chars> (e.g. ppk_live_a1b2c3d4...). Keys are user-scoped — each key acts as that user.
Where to manage them
- Onboarding → Claude step — one-click generation of a Claude-tagged key with the recommended scope set.
- Account → API access (
/account/api) — full UI: create, list, rotate, revoke. One user can have many active keys.
Scopes
| Scope | Allows |
|---|---|
articles:read |
List/read articles |
articles:write |
Create/update/delete articles |
posts:read |
List/read posts |
posts:write |
Create/update posts |
posts:publish |
Mark posts published (used by Make.com callback) |
Scopes are checked per request. A 403 means the key doesn’t have the scope the endpoint requires.
The purpose column
Every key has an optional purpose text field. ProPresence uses it internally to detect tooling-specific keys without relying on the user-editable key_name.
purpose |
Meaning |
|---|---|
claude |
Generated for Claude Cowork. Onboarding looks for purpose='claude' AND is_active=true. |
make |
Manual integration with Make.com (you’re free to set this yourself). |
null |
Generic key. |
When generating a key for a known integration, set purpose so ProPresence’s UI can surface it correctly. Detection always queries by purpose, never by key_name (users rename keys).
Rotation
Rotating revokes the old key immediately and shows the new one once. Old keys stop authenticating on the next request.
Storage
Keys are shown in full only at creation. Afterwards, only the masked prefix (ppk_live_a1b2c3d4****) is visible in the UI. Treat them like passwords — store in your secrets manager or in Cowork’s config.
Related: Authentication, Error codes