Audit log

The audit log is your account's console-governance trail: a who-did-what record of every mutating action taken in the admin console — members invited, roles changed, passwords reset, apps and users created or deleted, signing keys rotated. It is append-only and tamper-evident (every entry is linked into a per-account hash chain), and it is scoped to the tenant you are viewing. This guide shows you how to read it, page through it, stream new entries live, and pull it out for archival.

Before you start

The audit log is always tenant-scoped: you read one tenant's trail at a time, and every request must be made on that tenant's own host ({tenant-host}), never the canonical admin host. In the console this is automatic — the page shows the tenant you have selected; switch tenants to switch trails.

What an audit entry contains

Every fact the page renders is denormalised onto the row, so a deleted actor or target still displays correctly. An entry looks like this:

{
  "id": "b2f3a1c4-5d6e-4f70-8a91-0c2d3e4f5a6b",
  "actor_kind": "member",
  "actor_email": "ops@example.com",
  "action": "administration.member.invited",
  "target_type": "administration_member",
  "target_id": "9c8b7a65-4321-4d0e-9f8a-1b2c3d4e5f60",
  "target_label": "newhire@example.com",
  "extra": { "admin_role": "Viewer" },
  "created_at": "2026-07-16T12:00:00Z"
}

Read and page the trail

Entries come back most recent first. The response is a page envelope — items, plus a total count for the whole tenant and the limit/offset you asked for — so you can build a pager.

curl "{tenant-host}/v1/admin/audit?limit=20&offset=0" \
  -H "Authorization: Bearer {mgmtToken}"

{
  "items": [
    {
      "id": "b2f3a1c4-5d6e-4f70-8a91-0c2d3e4f5a6b",
      "actor_kind": "member",
      "actor_email": "ops@example.com",
      "action": "administration.member.invited",
      "target_type": "administration_member",
      "target_id": "9c8b7a65-4321-4d0e-9f8a-1b2c3d4e5f60",
      "target_label": "newhire@example.com",
      "extra": { "admin_role": "Viewer" },
      "created_at": "2026-07-16T12:00:00Z"
    }
  ],
  "total": 137,
  "limit": 20,
  "offset": 0
}

Stream new entries live

New entries arrive over Server-Sent Events (SSE), the same live transport the Activity page uses.

In the console, the Audit Log page opens the stream for you: while you are on the first page, new entries appear at the top the instant they happen — no refresh. (Live deltas only land on page 0; on older pages the window would shift under you, so the stream pauses there and the next page fetch reconciles the count.)

To consume the stream programmatically, subscribe to GET {tenant-host}/v1/admin/audit/events. SSE has no request-header channel, so a machine caller passes the token as the ?token= query parameter (not an Authorization header):

curl -N "{tenant-host}/v1/admin/audit/events?token={mgmtToken}"

Each new entry is delivered as an audit event; the server also emits :heartbeat comment lines (roughly every few seconds) to keep the connection alive:

:heartbeat

event: audit
data: {"idp_admin_id":"…","tenant_id":"…","id":"b2f3a1c4-…","actor_kind":"member","actor_email":"ops@example.com","action":"application.created","target_type":"oauth_client","target_id":"…","target_label":"Billing Portal","extra":null,"created_at":"2026-07-16T12:03:11Z"}

The data payload is one audit entry plus its routing keys (idp_admin_id, tenant_id); the stream is filtered to the tenant named by the host, so you only receive that tenant's events. The same audit:read capability gates the stream.

Export the trail

Walk offset forward in limit-sized pages (up to the 500-per-page cap) until you have total entries, and write each page's items to a file. For example, pulling everything into newline-delimited JSON with jq:

offset=0
limit=500
while : ; do
  page=$(curl -s "{tenant-host}/v1/admin/audit?limit=$limit&offset=$offset" \
    -H "Authorization: Bearer {mgmtToken}")
  echo "$page" | jq -c '.items[]'
  count=$(echo "$page" | jq '.items | length')
  total=$(echo "$page" | jq '.total')
  offset=$((offset + count))
  [ "$count" -eq 0 ] && break
  [ "$offset" -ge "$total" ] && break
done > audit-export.ndjson

Because the trail is append-only, an export is a point-in-time snapshot: run it on a schedule (for example nightly) if you need a durable archive outside SenseCrypt.

How entries are protected from tampering

The audit log is append-only by design — there are no update or delete routes — but that alone doesn't stop a privileged operator with direct database access from editing or removing a row after the fact. To make any such change detectable, every entry is linked into a per-account hash chain: each row stores a SHA-256 row_hash computed over its own content plus the previous row's hash, so editing any field changes that row's hash, and deleting a row orphans its successor's back-link. Either kind of tampering breaks the chain and is caught by an integrity check that recomputes it and reports the first row that doesn't verify.

Verify your setup

Confirm the trail is live and scoped correctly:

Learn more