The audit log

Every governance action in your tenant is an audit event: who did what, when, with what outcome. Admins read it under Team → Audit, or programmatically at GET /audit-events.

What is recorded

• Sign-ins, refused sign-ins and why (sign_in.failure with a reason such as email_unverified, issuer_mismatch, member_not_provisioned).
• Invitations created, revoked and claimed; role changes; removals; settings changes (including switching Trust unverified email).
• Machine credentials created, revoked and refused (credential_revoked, credential_expired).
• Reading the log itself. Each list call records one audit.read event with the scope that was read, so “who looked at the audit log” is answerable. Those rows are hidden from the default listing and shown on demand with ?action=audit.read; every export includes them.

The trail is append-only: the application role holds no delete privilege on it at the database, and the only deletion path is the retention sweep described below.

Paging and bounds

Parameter	Default	Bound
limit	one screenful	at most 200 per call
offset	0	at most 100,000
since / until	open	must fall between 1970 and the year 2400

Over-bound requests are refused with the bound named; nothing is silently truncated.

Retention

Audit events are kept for the deployment’s AUDIT_RETENTION_DAYS (default 365). A per-tenant window (audit.retention) is part of the commercial edition; reading and clearing an existing policy is available on every edition. Changes to the window are themselves audit events. The sweep runs nightly in the batch worker; if your operator is not running the worker, nothing is deleted and nothing warns except the operator’s health check.

Export

Bulk export is a commercial entitlement (audit.export). On the open-source edition the route answers 402 entitlement_required; page through GET /audit-events instead.