> ## Documentation Index > Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt > Use this file to discover all available pages before exploring further. # Audit Log > Review every action performed in your organization — who did what, on which resource, when — with actor, action, resource, and date filters, CSV/JSON export, and a webhook stream for your SIEM. # Audit Log The Audit Log is the tamper-evident ledger of everything that happens inside your organization. Every entry answers four questions: **who** did it, **what** they did, **which resource** it touched, and **when**. Open it from **Settings → Audit log**. The page covers actions performed within your organization — creating an API key, changing a role, updating a flow, transferring credits, uploading a file, and hundreds of other operations — recorded automatically as they happen. ## What is captured Each entry records: * **Actor** — the team member who performed the action (name and email), or, for automated work, the responsible system actor: a background service, scheduled job, API key, or integration. Rows with no acting user are labeled explicitly rather than left blank, so a reviewer can always tell a machine action from a missing record. * **Action** — a human-readable phrase such as *Subaccount created* or *Credits transferred*, colour-coded by operation type (create, update, delete). The underlying machine event code is preserved: it appears on hover and in the expanded technical details. * **Resource** — the affected resource's type (organization, subaccount, file, configuration, …) and name where one is recorded, plus the full resource ID with a copy control and a deep link to open the resource in the dashboard. * **Timestamp** — date and time to the second, rendered in your timezone with the zone abbreviation shown, so a row can be correlated against server logs and external records without ambiguity. * **IP address** — the source IP of the request that caused the action, where applicable. * **Details** — a structured before/after payload for the change. Expand any row to see the full event code, the actor attribution for system actions, and the recorded detail JSON. Entries are append-only: the log is a chain, and rows cannot be edited or deleted through the dashboard or API. ## Access and permissions The Audit Log is restricted to **owners and admins**. Other roles see an access-restricted notice instead — ask your organization owner to elevate a member who needs audit access. Open **Settings → Audit log**. The page loads the most recent entries, newest first. Select **Load more** to page further back; the page keeps every loaded row in a virtualized table, so long review sessions stay responsive. ## Filter and search The filter bar narrows the ledger from four directions, and filters combine: * **Search** — free text matched against the action (both the readable phrase and the machine code), the resource type and ID, and the user name. Paste a resource ID taken from anywhere in the dashboard to find its history. * **User** — restrict to one team member. * **Action type** — narrow to created, updated, or deleted entries. A bare verb matches every action of that type. * **Actor** — *human* (operator actions) or *system* (automated and internal events). The ledger includes the platform's own automated work; isolating human actions is the fastest path during a security review, and isolating system actions explains what an automation did. * **Date range** — last 24 hours, 7 days, 30 days (default), 90 days, or all time. A **Clear filters** control appears whenever any filter is active, so a narrowed view is always one click from the full ledger. ### Deep links Other dashboard surfaces link directly into a pre-scoped view. A resource's *Audit log* link (for example, on a conference's detail page) opens the ledger filtered to that single resource and across all time. The Billing dashboard's *Billing Activity* link opens the ledger scoped to the complete billing action namespace. These URLs are stable — bookmark or share them when a recurring review needs the same slice. ## Export and retention Two export paths cover different scales: * **Quick export (CSV or JSON)** — the buttons at the top of the page download exactly what you are looking at: your active user, action, actor, and search filters are applied to the file. This path caps at 10,000 rows; a capped download is flagged so a partial file is never mistaken for the complete ledger. Suitable for a focused review or a single-incident evidence pull. * **Full export** — the *Full export* menu queues a background job that streams the complete audit history for the selected date range to a file, with no row cap. When the job finishes you receive a download link (valid for 7 days); expired links can be re-queued. Use this for a compliance evidence pull or a data-subject request that must cover the whole ledger. Export endpoints are rate-limited to a few requests per minute per organization. Audit entries persist without a fixed expiry — the ledger is your organization's action history, and entries are not pruned by age. Regular exports are still good practice for organizations that must retain evidence under their own archival policy. ### Stream to your SIEM For continuous monitoring, subscribe to the `audit.log.created` webhook event. Every new audit entry is delivered to your endpoint as it is written, so a SIEM or log pipeline receives the ledger in real time instead of through periodic exports. See [Webhook Events](/webhooks/events) for payload shape and subscription setup. ## Common use cases * **Security review** — answer "who changed this, and when?" for an API key, a role change, a sign-in setting, or a wallet-affecting action. Combine the *human* actor filter with a resource search to isolate operator behaviour from system noise. * **Compliance evidence** — the log is a control your organization owns: you can present entries and exports as evidence of who did what in your tenant. Whether that evidence satisfies a specific framework (SOC 2, GDPR accountability, HIPAA) depends on your own policies and how you operate the account — Devotel Orbit supplies the record; the posture remains yours. * **Incident response** — during an incident, filter by the affected resource and read the before/after detail rows to reconstruct the exact sequence of changes, then use the timestamp-to-the-second to line the entries up with external logs. ## Audit Log vs notifications vs delivery logs These surfaces answer different questions: * **Audit Log** — *what changed in my organization, and who changed it?* A permanent, per-action record for security and compliance, restricted to owners and admins. * **[Notification Center](/guides/in-dashboard-notifications)** — *what needs my attention right now?* A triage feed of alerts (failures, security signals, campaign completions) for every dashboard user. Notifications are ephemeral and actionable; audit entries are permanent and evidentiary. Security-relevant actions often appear in both — the notification tells you it happened, the audit entry proves who did it. * **[Delivery log](/guides/delivery-log)** and webhook delivery inspections — *did this message or event reach its destination?* A message-delivery and webhook-delivery record, scoped to communication traffic rather than account actions.