Audit logs
Every mutating API call is captured; actor, action, resource, body, timestamp.
ZopDay captures every mutating API call (POST, PUT, PATCH, DELETE) to an append-only audit trail. The same data drives the in-app Audit Logs page and powers compliance evidence collection. Nothing mutating happens without a row.
What gets captured
Each audit row records:
- Actor: the signed-in user or the PAT that initiated the request
- Method and path: the HTTP verb and the URL, with IDs preserved
- Resource type and resource ID: the logical resource being acted on
- Request body: the full body, with secret-shaped fields redacted (passwords, tokens, secrets, API keys, etc.)
- Response body: the full response, with the same redaction applied
- Status: HTTP response status
- Timestamp: server time of the request
Read-only operations (GET, HEAD) are not captured; the volume would dwarf the mutation log without adding compliance value.
Where to view audit logs
In-app: Settings → Audit Logs.
The page supports server-side filtering by method, resource, status, and actor; full-text search; and expandable request / response body panels for each row. Failed mutations are prefixed in the description column so they stand out at a glance.
CSV export
Click Export CSV on the audit log page with any active filters to export the matching set. The export runs as a background goroutine so your browser doesn’t have to stay open. When the export completes, ZopDay surfaces a signed download URL on the originating page. The link is time-limited; if it expires before you download the file, re-run the export to generate a fresh URL.
RBAC
Viewing the audit log requires the audit-log:view policy. The audit log is not auto-visible to all users; many orgs scope it tightly to security and compliance teams.
Custom roles need an explicit audit-log:view grant.
Per-org isolation
Audit logs are strictly per-org. There is no cross-org view, no admin “see everything” mode, and no API that returns rows from a different org’s stream. Each org’s audit data is scoped at the database layer.
Common queries
| Question | How to find it |
|---|---|
| ”Who deleted that environment yesterday?” | Filter: method=DELETE, resource type=environment, time window=yesterday |
| ”What changed in production in the last hour?” | Filter: time window=last hour, status=2xx, resource type=deployment |
| ”Did this user have access to do this?” | Filter: actor=email; the request body shows the resource ID; verify policy in Settings → Roles |
| ”Why did this deploy fail?” | Filter: status=4xx/5xx, resource type=deployment, time window=around the failure |
| ”What did the IAM import wizard write?” | Filter: resource type=user / team / role, time window=around the import |
What’s redacted
Field-name-based redaction strips obvious secret-shaped fields (password, token, secret, apiKey, clientSecret, etc.) from both request and response bodies before storage. Field names not on the redaction list pass through, so don’t put secrets in oddly-named fields.
Bodies are also size-capped; bodies over the cap are replaced with a truncation marker so the audit log never becomes a storage mechanism for large payloads. Contact support if you need a per-endpoint cap override for a specific high-stakes operation.
SIEM forward
On the Enterprise tier, the audit feed can forward to your SIEM (Splunk, Datadog, Sumo Logic, generic syslog, or object storage). Contact your account team to enable forward and configure the destination.