Audit log API

Read your team's audit log over the Servor API with an audit:read token — a chronological record of who did what, for compliance and security review.

Read your team's audit log over the API. The audit log is a chronological record of significant actions in your team — who did what, and when — which makes it the backbone of any compliance export, security review or SIEM integration you want to build on top of Servor.

This endpoint requires the audit:read scope.

get/v1/auditScope: audit:read

List audit entries (paginated)

Parameters

actionstringquery · optional
Filter by action-type prefix, e.g. "incident.".
limitintegerquery · optional
Page size, 1–100 (default 50).
cursorstringquery · optional
Opaque cursor from a previous response's nextCursor. Omit for the first page. An unrecognised cursor is ignored and the first page returned.

Example request

curl https://api.servor.app/v1/audit \
  -H "Authorization: Bearer sv_live_..."

Example response

{
  "items": [
    {
      "id": "uuid",
      "actionType": "incident.created",
      "resourceType": "incident",
      "resourceId": "uuid",
      "ipAddress": "203.0.113.10",
      "createdAt": "2026-08-20T10:00:00.000Z"
    }
  ],
  "nextCursor": "djEuMDE5ZWNkMzc..."
}

What you get back

GET /v1/audit returns audit entries for your team, most recent first. Each entry captures an action and the actor who performed it, so you can answer "who changed this, and when?" long after the fact.

curl https://api.servor.app/v1/audit \
  -H "Authorization: Bearer sv_live_..."

Walking a log that is being written as you read it

The response is an envelope: items and nextCursor. While nextCursor is not null, pass it back as ?cursor= to get the next page.

curl "https://api.servor.app/v1/audit?limit=100&cursor=djEuMDE5ZWNk..." \
  -H "Authorization: Bearer sv_live_..."

Why a cursor and not a page number

A log gains new entries while you are walking it. With ?page=2, entries that arrived in between push older ones across the boundary: you see some twice and miss others entirely, without a single error. An audit export that is quietly incomplete is the worst possible failure. A cursor names a specific row, so whatever arrives above it never shifts what comes next.

An unrecognised cursor is ignored and the first page returned — never an error.

Regular exports

For compliance you'll usually want to pull the audit log on a schedule and store it in your own system. Keep polling within the rate limits — a periodic export, not a tight loop.

Audit log vs. command history

Both are records of activity, but they answer different questions:

	Audit log	Command history
Scope	Team-wide actions	Commands run on one server
Answers	"Who changed this?"	"What was run here?"
Scope needed	`audit:read`	`commands:read`

Use the audit log for team and account activity; use command history for the exact commands executed on a given server.

Notes

The audit log never contains secrets, passphrases or encrypted payloads — only the fact that an action happened and who performed it.
The same log is browsable in the dashboard — open the audit log in Servor.
A 403 means your token is missing the audit:read scope. See errors for the full list of status codes.

Audit log API

What you get back

Walking a log that is being written as you read it

Audit log vs. command history

Notes

See also