Open Audit with audit:read. Reading audit information can require recent MFA verification. Filter by text, outcome or event type, choose visible columns and use View to inspect an event’s JSON detail.
Events record the actor, type, success/failure/denied outcome, relevant environment/VPN/queue/job scope and request/correlation/trace context. Use them to investigate denied access, administrative changes and operation outcomes. Fields that do not apply are omitted; sensitive values are redacted. Treat upstream failure descriptions as untrusted diagnostic text.
Audit is append-only during normal operation. Retention is configurable in Admin → Settings: 0 keeps events indefinitely; finite windows are 90–3,650 days, default 365. All updates require recent MFA; reducing audit retention also requires Global Admin. Set retention for your organization’s investigation and data-handling requirements before relying on historical evidence. Changes cannot recover purged events.
Compliance evidence API
The evidence API produces signed point-in-time summaries of platform configuration and audit activity. It is not a message archive or a declaration of regulatory compliance. There is no dedicated evidence page in the v1.7.1 navigation.
Use an authenticated administrator with admin:manage. Generation and export require recent MFA step-up; use a human session, not an unattended sop_ token.
| Method and path | Purpose |
|---|---|
GET /api/v1/compliance/evidence | List evidence summaries. |
POST /api/v1/compliance/evidence | Generate evidence; optional JSON periodDays from 1 to 365, default 90. |
GET /api/v1/compliance/evidence/{id} | Read a bundle. |
GET /api/v1/compliance/evidence/{id}/export?format=json | Download JSON; csv, pdf and xlsx are also supported. |
For example, the generation request body for the preceding month is:
{"periodDays": 30}Exports include the content hash and HMAC-SHA256 signature. HMAC verification depends on a protected installation signing key; it is not public-key verification. Retain exported evidence and provenance under your own access controls. Only the first configured signing key is used, with no old-key verification fallback; plan retention before rotating it.
The API’s background scheduler generates evidence every seven days of process uptime and purges expired evidence daily, with an initial purge shortly after startup. It is disabled in tests or with COMPLIANCE_SCHEDULER_ENABLED=false. It has no multi-replica generation coordination, so multiple API replicas can generate separate bundles. It is distinct from user-created message schedules.
Evidence retention defaults to 90 days. A saved retention change affects newly generated bundles; existing bundles keep their recorded expiry. Message references expire independently, normally after one hour, with an additional age-based retention cap. PostgreSQL backups can retain older data beyond the application’s live retention window; manage their lifecycle separately.