Audit log
The audit log is the tamper-evident record of who changed what in your store. Every settings, integration, billing, team, and content change is captured with the actor, a timestamp, and a JSON diff of what the value was before and after. It lives at Dashboard → Audit logand is the first place to look when you need to answer “who turned this on?” or “when did this change?”
What gets logged
Audit entries are written across the product wherever a meaningful change happens. The action name is a domain.action string, so entries group naturally by area. A non-exhaustive map of what you will see:
| Area | Example actions |
|---|---|
| Rules & merchandising | rule.created, rule.updated, rule.toggled, rule.bulk_deleted, merchandising_rule.created, objection.updated |
| Automations | journey.created, journey.status_updated, playbook.installed, playbook.custom_created, agent_playbooks.updated |
| Support & conversations | ticket.updated, ticket.bulk_updated, conversation.escalated, conversation.closed |
| Knowledge & training | knowledge.document_created, store_facts.updated, training_enrichment.accept |
| Team & access | team_member.invited, team_member.role_updated, team_member.removed, api_key.created |
| Integrations & sync | integration.connected, sync.triggered, webhook.created, theme.exported |
| Billing | billing.stripe_plan_changed, billing.tier_changed, billing.downgrade_starter |
| Compliance | gdpr.data_deleted, credential.rotate, store.deleted |
Both sides of the change
Reading an entry
Each row shows four things:
- Action — the
domain.actionname as a badge. - Timestamp — when it happened, in your local time.
- Actor— the teammate's name or email. Changes made by background jobs or webhooks (for example a Stripe webhook or a GDPR job) show as system.
- Diff — the before/after JSON, when present.
Filtering
The filter box matches the action name as a prefix or substring — type billing. to see only billing events, rule. for rule changes, ticket. for ticket triage, and so on. It is a case-insensitive contains match on the action, so partial names work too. The view loads the most recent 200 entries for the store, newest first.
Scope and depth
Who can view
The audit log is part of the merchant dashboard, so it requires access to the store. It is most useful to owners and admins reviewing security and configuration changes; it sits alongside the security and compliance surfaces rather than the day-to-day operational tabs. Entries are append-only from the application — the log records actions, it does not let you edit or delete past entries from the UI.
Retention
Audit entries are retained as part of your store's compliance data. They are not subject to the shorter conversation-retention window — configuration history is kept so you can answer audit and security questions after the fact. If your plan or region has specific retention requirements, confirm them on the security page.
When to use it
- Security review — confirm who rotated a credential, changed a role, or revoked an API key.
- Change forensics — a journey started sending or a rule stopped firing; find the exact change and actor.
- Billing disputes — trace plan changes, downgrades, and webhook-driven tier changes.
- Support triage trail— see how a ticket's status, priority, or assignee moved over time (see Support tickets).
Related
- Security & compliance
- Support tickets — triage actions land in the audit log
- Conversations
- Webhooks — for streaming events to external systems