Logs — the request trail

What gets written

The auth layer writes a request-log row on every authenticated platform-key and site-key request — this is not opt-in instrumentation, it is how the API works. Each row carries:

• method, path and status code,
• the module the endpoint belongs to — so usage per capability is a filter, not a guess,
• the key that made the call (by name), response time in ms, and the request origin,
• the caller's IP and user agent — encrypted, with a hash column so abuse investigation can still ask "everything from this address" without storing readable PII.

The read surface

Granting the logs module lets the platform's own dashboard read its slice:

GET /api/platform/logs?method=POST&module=records&status=4xx&q=/records/

• Filter by method, by module, by status class (2xx/3xx/4xx/5xx); search by path substring.
• Newest first, paginated.
• The viewer's own polling is hidden by default (rows are still written; the default listing excludes the logs path) — the log viewer must not become the loudest thing in the log it shows.

What it's for

• Debugging integrations — see the exact status and timing of the call a client site just made, and the origin it came from (origin-allowlist problems are debugged by reading this field).
• Usage — which modules and keys are actually exercised.
• Incident forensics — "what the hell happened" at 3am, answerable from the platform's own dashboard rather than a support ticket to Dash4Devs.

Separately from this per-platform trail, superadmin actions on the platform (key issuance, reveals, module changes, suspensions) land in an audit log with the actor attached — see the audit trail.