Skip to main content
The request log is a durable, searchable record of every authenticated request that reaches the /v1 surface of the Zeptar API. You do not need to instrument anything — logging happens at the infrastructure level via a global interceptor that runs after authentication succeeds. Each entry captures the HTTP method, path, response status, latency, the request ID for cross-referencing support tickets, and — when a request was made with an API key — which key was used.

​
What gets logged

Every request to /v1 that passes authentication is recorded. The only exceptions are the request-log endpoints themselves (GET /v1/request-log, GET /v1/request-log/stats, GET /v1/request-log/export) — reading the log does not append to it. Unauthenticated requests that are rejected before auth resolves are not logged.

​
Retention

Log entries are kept for 30 days and then deleted automatically. If you need a permanent record, export the data before it ages out (see Exporting entries below).

​
Endpoints

​
List entries — GET /v1/request-log

Returns a paginated list of log entries for the active workspace, newest first. Use this to build a custom audit view or to inspect traffic programmatically. Query filters

​
Summary statistics — GET /v1/request-log/stats

Returns aggregated counts and a time-series breakdown for the filtered window. Useful for rendering a traffic graph or a quick health summary on the dashboard. Accepts the same filter parameters as the list endpoint.

​
Export — GET /v1/request-log/export

Streams the filtered result set as a CSV file (Content-Disposition: attachment; filename="request-log.csv"). Columns are: Time, Method, Path, Status, Latency (ms), API key, Request ID. Use this to pull data into a spreadsheet, SIEM, or external analytics pipeline. Accepts the same filter parameters as the list endpoint.

​
Session-only access

All three request-log endpoints require an active browser session. They cannot be called with an API key. Attempts to access the log via a Bearer token return 403 session_required. This is intentional — the request log includes metadata about every key in the workspace, so reading it is scoped to interactive dashboard users who have already authenticated as organization members.