Audit log

The /audit page is a near-real-time record of every authenticated request the platform has processed for your tenant. Visible to every role — every column shown is metadata; PII is never logged here.

What each row records

Column	Notes
Timestamp	UTC, displayed in the viewer's local timezone.
Endpoint	The HTTP method and path that was called (POST /v1/ocr, POST /v1/face/verify, GET /v1/sessions, …).
Status	The HTTP response code. Coloured: green for 2xx, amber for 4xx client errors, red for 5xx platform errors.
Latency	Wall-clock duration in milliseconds, gateway-side (does not include client network time).
Request ID	The request_id returned to the caller. Quote this in support tickets; the platform team can pull a full trace from it.
Key / session	Either the truncated key id (sk_live_aBc…) that authenticated the request, or the JWT jti of the session token.
Error code	error.type from the response envelope when status is non-2xx (validation_error, expired_token, feature_disabled, …).

Filters

Filter rows down by combining any of:

• Endpoint — substring match against the path. ocr matches every OCR endpoint; face/verify narrows to just 1:1 face match.
• Status — exact match, e.g. 400 or 429. Useful for "show me every rate-limit hit in the last hour".
• From / To — datetime-local pickers. Inclusive on both ends. Converted to UTC for the query.

Filters compose with AND. The "Reset filters" button clears all four inputs and the pagination cursor in one click — otherwise a cursor pointed at row N might not be valid after the filter set changes.

Mode toggle

The audit log respects the global live ⇄ test toggle (top of the page). Live-mode requests and test-mode requests are bucketed separately so you can review them independently.

Pagination

The list is cursor-paginated (UUIDv7 ids walk back monotonically). Each "Load more" request fetches the next page and stacks it below the current rows. Total row count isn't shown — there's no efficient way to compute it for a tenant with millions of audit rows.

What's NOT in the audit log

The audit log focuses on API traffic. It deliberately excludes:

• Dashboard browsing — what pages you opened in the dashboard is not recorded as audit rows (the page-view stream is separate; ask ops if you need a forensic timeline).
• PII or request/response bodies — only metadata is retained. To recover the body of a specific request, you'd need the platform team to look it up by request_id (out-of-band, subject to your contract).

Dashboard mutations (creating a key, removing a user, etc.) are recorded — see "Dashboard events" below.

Dashboard events

In addition to API traffic, the audit log shows events generated by dashboard mutations. These rows have:

• A synthetic endpoint like dashboard:keys.create, dashboard:team.remove, dashboard:webhooks.rotate-secret.
• The dashboard user id of the actor in the Key / session column.
• A masked source IP in Notes (last octet zeroed out for compliance).

This is how an admin spots after-the-fact "someone minted a live key at 03:00 last Saturday — who?". The actor's email is resolvable from the user id via the Team page.

Retention

Audit rows are retained per your contract. For most tenants this is 90 days hot (queryable from the dashboard) and a year cold (exportable on request). Older data is purged.