Skip to main content
The Backoffice Logging endpoints let authorized Backoffice users retrieve stored Zylon logs for investigation, review, export, or integration jobs. This page covers manual retrieval only. For external syslog or HTTP delivery, see Log Delivery and Storage configuration. These endpoints are read-only. The documented API exposes GET operations for listing stored logs and usage data; it does not expose per-record update, patch, or delete operations.

Authentication and permissions

Workspace-only tokens are not enough for these endpoints.
For operator-facing guidance on governance, evidence preservation, and SIEM delivery, see Auditability & AI Governance: Logging, Evidence, and SIEM Delivery.

Endpoints

Pagination

The two log list endpoints return a page envelope:
Supported page parameters: Logs are ordered by start_timestamp descending. The backend adds log ID ordering as a stable tie-breaker.

Shared log filters

GET /v1/platform/logs and GET /v1/platform/gateway/{gatewayId}/logs support these query parameters:
Without include, input_payload and payload are returned as empty objects and data is omitted. Use include=Data for structured per-event data. Add chat-specific include values only when needed.
The include parameter controls retrieval shape only. It does not enable or disable collection. If request messages or responses are present in stored chat logs, they are returned only when the caller requests the corresponding include value.
Retrieving very large chat logs can take time, especially when the requested scope is large or when messages and responses are included.

Event families and actions

This event list covers documented application events. Helm-level logging configuration changes, such as changing retention or delivery destinations, should also be captured through customer change-management, GitOps, Kubernetes audit, or infrastructure audit controls.

Log record schema

Each item returned by the log list endpoints is a ZylonLogDTO. Structured data can include workspace, HTTP, security, chat, embed, or ingest fields. Chat data can include model, token counts, request metadata, optional request messages, optional response, latency metrics, and tools_used. Sensitive request keys such as passwords, tokens, API keys, secrets, credentials, cookies, and connection strings are masked before request input payloads are stored. Do not build export workflows that require recovering masked values from logs.

List platform logs

Retrieves stored logs across gateway, workspace, backoffice, and security event families.

Example request

Example response

List gateway logs

Retrieves stored logs for one gateway. The {gatewayId} path parameter is applied by the backend and overrides any gatewayId query parameter.

Example request

List AI usage logs

Returns a non-paginated list of limited AI usage records. This endpoint is optimized for usage charts. It returns data related to AI usage only: token consumption, tools used, and usage events for chat, embedding, and ingestion activity. It does not return full log payloads, request prompts, full responses, security events, workspace audit records, or backoffice events. Use the log list endpoints with include when you need full stored log records.

Usage filters

Usage response schema

Example request

Example response

Errors and limitations

Export chain of custody

When using these endpoints for a manual export, preserve evidence outside the response body:
  • operator account or token identity;
  • request timestamp, source IP, and request ID when available;
  • exact URL filters, pagination values, and include values;
  • number of records exported;
  • incident, ticket, or legal hold reference.
Log retrieval calls are also logged as Backoffice actions: /v1/platform/gateway/{gatewayId}/logs emits backoffice.gateway_logs.read, and /v1/platform/logs emits backoffice.logs.read. Preserve those events together with the exported response when a review, incident, or legal hold requires evidence of who accessed log records.