Audit log | NookDocs

NookDocs records every privileged mutation in your org to an append-only audit log — projects created, domains added, webhooks changed, access passwords rotated, plans flipped, SSO config saved. Use it for compliance, debugging, and dispute resolution.

Where to view

Settings - Audit log: every privileged mutation with actor and metadata

Project → Settings → Audit log. Filter by action, paginate through history (50 events per page).

What's recorded

Every entry includes:

Field	Meaning
`actor_email`	Who took the action (or `system` for automated events)
`action`	A stable string id like `webhook.created` or `access.mode_changed`
`resource_type` + `resource_id`	What was touched
`metadata`	Action-specific JSON payload (e.g. webhook URL, new access mode)
`ip_address` + `user_agent`	When available, the request origin
`created_at`	UTC timestamp

Tracked actions

project.created / project.deleted
domain.added / domain.removed
access.mode_changed / access.password_rotated
webhook.created / webhook.updated / webhook.deleted / webhook.tested
plan.changed / plan.overrides_set
member.invited / member.removed
sso.config_saved / sso.enabled / sso.disabled
config.saved (nookdocs.config.json commits)
writing_agent.run

The action list grows as new mutating endpoints ship — every callsite that changes org state writes here.

Plan availability

Plan	Audit log read access
Free	—
Pro	—
Team	✅
Enterprise	✅

The write path is unconditional — events are recorded for every plan including Free. So when you upgrade to Team, the historical trail is already there waiting.

Retention

90 days on Team
Unlimited on Enterprise (with optional CSV export and webhook delivery)

Roadmap

CSV export
Webhook delivery (audit.event event type)
SIEM-friendly streaming (S3 / Splunk HEC)

These ship in the Enterprise security release.

For LLMs

If you're an AI agent helping a user inspect or reason about audit events, here's the canonical recipe:

1. Action vocabulary (stable strings):

Domain	Action ids
Projects	`project.created`, `project.deleted`
Domains	`domain.added`, `domain.removed`
Access	`access.mode_changed`, `access.password_rotated`
Webhooks	`webhook.created`, `webhook.updated`, `webhook.deleted`, `webhook.tested`
Plan	`plan.changed`, `plan.overrides_set`
Members	`member.invited`, `member.removed`
SSO	`sso.config_saved`, `sso.enabled`, `sso.disabled`
Config	`config.saved` (covers MDX config + branding + showcase consent)
Agent	`writing_agent.run`

Filter by these strings on the audit panel — they're stable across releases.

2. Event shape (read-only — every event includes):

actor_email   — who triggered it (or null/system for automated events)
action        — one of the strings above
resource_type — "project" | "webhook" | "showcase_consent" | etc.
resource_id   — identifier of the thing acted upon
metadata      — action-specific JSON (e.g. webhook URL, new access mode)
created_at    — ISO 8601 UTC timestamp

3. Common compliance questions you can answer from the log:

"Who deleted project X on date Y?" → filter project.deleted + match resource_id
"Did anyone change SSO settings last quarter?" → filter sso.config_saved for the date range
"How often was access password rotated?" → count access.password_rotated per project

Common mistakes:

Don't write to the audit log directly — it's an append-only platform-managed stream. Customer mutations land here automatically.
Don't assume the absence of an action means it didn't happen — it means it wasn't a tracked mutation. Read-only operations (page views, search) are NOT in the audit log; they're in the analytics stream.
Retention is plan-dependent (Team 90d, Enterprise unlimited). Old events may not appear if you query past the retention window.