The audit trail
Who did what to a platform — with a name attached, months later.
Updated
On this page
Actions with names on them
Administrative actions against a platform land in a dedicated audit log, each row carrying the actor, the action, an encrypted detail payload (key names, comp reasons, module diffs) and the actor's IP (encrypted). The recorded vocabulary covers:
- Platform lifecycle — created, updated, suspended, activated, modules changed.
- Keys — issued, revealed, revoked; allowed origins added, updated, removed.
- Billing — updated, payments skipped, payments resumed.
- Schema — record types created and deleted.
- Users — platform users created, updated, deleted, password reset.
Why reveals are logged
Key values can be re-revealed by a superadmin under a verified sensitive-operation check — that is an accountability decision: the alternative (unrecoverable keys) just makes people store them in worse places. The trade is that every reveal is an audit row with a name on it.
Two trails, two questions
| Request log | Audit log | |
|---|---|---|
| Answers | "What did the API do?" | "Who changed the platform?" |
| Written by | The auth layer, every request | Administrative actions |
| Readable by | The platform (logs module) | Superadmins |