identity.delete event still names the address.
Events are org-scoped and never carry secret values — no passwords, no TOTP seeds, no session state, no cookies. meta holds descriptive fields only.
The audit event object
There is no actor field. Events record what happened to which resource, not which API key or dashboard user did it. If you need per-actor attribution, use a separate API key per caller and correlate by time.
Actions
Every action the API emits today:Run outcomes (
completed, failed, blocked) are not audit events — they live on the run itself and on the run.* webhooks. The audit trail records deliberate acts on credentials, sessions, accounts, and takeover, not the automation’s own progress.List audit events
GET /v1/audit-events
200: an array of audit event objects, newest first.
Paging a long trail
Paging a long trail
There is no cursor, no offset, and no
until — the only window control is since, and results always come back newest-first. That makes two patterns possible and one impossible:- Tail-following works. Keep the newest
createdAtyou have seen and pass it assinceon the next call to get everything after it. This is the right shape for a monitor that mirrors the trail into your own store. - Narrowing works. Filter by
actionand raiselimitto 200 to pull a specific slice. - Walking backwards into deep history does not. An earlier
sincereturns the newest 200 again, not an older page. If you need the full history, mirror it forwards from the start rather than trying to paginate into the past.
This is HTTP-only. Neither SDK nor the CLI wraps the audit trail; the dashboard renders the same data on the Security tab.
Related
Audit trail
What to monitor and how the trail is used.
Security
The vault, the key, and what Sente does not have.
Connections
Write-only credentials and revocation.
