Skip to main content

Enterprise audit trail

Programmatic, admin/owner-only access to the same audit events available in your Enterprise dashboard — who did what, to which resource, and how access changed.
The Audit Logs API lets you retrieve your enterprise team’s audit events over HTTP, so you can stream them into a SIEM, build compliance reports, or power your own security monitoring. It exposes the same activity feed as the dashboard, projected to a customer-safe set of fields. Available exclusively for Enterprise plans with audit logs enabled, and only to team admins and owners. It does not consume credits.

Key capabilities

  • Complete activity feed: every governance, project, and member action your team produces — role changes, shares, permission grants, API-key lifecycle, and more.
  • Rich filtering: narrow by actor (member_id), group (group_id), folder (folder_id), event type (event_type), a single request (request_id), or a date window.
  • Cursor pagination: walk your entire history reliably with an opaque cursor — no offset limits, no skipped or duplicated rows.
  • Server-side name resolution: project and folder names are resolved for you, so you don’t have to join against other endpoints.
  • Customer-safe payloads: the free-form event data is narrowed to a vetted allow-list — provider internals, cross-system identifiers, and moderation flags never leave your boundary.
  • No credit cost: reading your own audit trail is free.

Use cases

  • SIEM / SOC ingestion: forward audit events into Splunk, Elastic, or Datadog for centralized security monitoring.
  • Compliance & audit reporting: produce evidence of access changes and administrative actions for SOC 2, ISO 27001, or internal reviews.
  • Access reviews: reconstruct who granted which permission, to whom, and when.
  • Incident investigation: pivot on a request_id to pull every event emitted by a single operation.
  • Anomaly detection: stream events into your own pipeline to flag unusual role changes or bulk shares.

Read audit events

Fetch events with GET /v1/analytics/audit-logs/events. Authenticate with your API key — your enterprise team and identity are resolved automatically.

Example response

Event structure

Each event describes one action, the actor behind it, and where it came from.

Customer-safe by design

The action.data, action.old_state, and action.new_state objects are free-form. On the API they are narrowed to a vetted allow-list — provider/inference internals, cross-system identifiers, internal billing state, and content-moderation flags are stripped and never returned.

Filtering

Combine any of these query parameters. Multi-value filters accept a single value, a comma-separated list (member_id=1,2), or repeated params (member_id[]=1&member_id[]=2).

Pagination

Two modes, depending on what you need:

Page mode

Use page and per_page (max 100) for browsing. page * per_page cannot exceed 10000 — narrow the date range or switch to a cursor for deeper reads.

Cursor mode

Pass cursor to iterate with no depth limit. page is ignored. Follow meta.next_cursor until it is null to walk your whole history.
To sync your full trail, request the first page, then keep calling with the returned meta.next_cursor until it comes back null.

Authentication

Authenticate with the X-Magnific-API-Key header. Your enterprise team and identity are resolved automatically from the API key. The key must belong to a team admin or owner of an Enterprise team with audit logs enabled. See Authentication for details.

Retention

The audit index retains at most 15 days of events. Queries cannot span a wider window. For long-term retention, stream events into your own storage on a schedule.

Rate limits

The Audit Logs API is limited to 500 requests per day per API key, with a short-term burst cap. Use cursor pagination and incremental syncs to stay well within budget.

API reference

GET /v1/analytics/audit-logs/events

Search and stream your enterprise audit events with filters and cursor pagination

Best practices

  • Sync incrementally: after a full backfill, poll a small recent window (e.g. the last hour) on a schedule instead of re-reading everything.
  • Use the cursor for backfills: page mode is capped at 10000 results; the cursor has no depth limit and never skips rows.
  • Persist your own copy: retention is 15 days — export to your storage if you need history beyond that.
  • Pivot on request_id: when investigating an incident, grab one event’s request_id and re-query to see every related event.
  • Handle 429: back off and retry when you hit the daily or burst limit.

Frequently Asked Questions

It’s a read-only HTTP endpoint that returns your enterprise team’s audit events — who did what, to which resource, and how access changed. It exposes the same activity feed as the Enterprise dashboard, projected to a customer-safe set of fields.
Only team admins and owners of an Enterprise team that has audit logs enabled. The caller is resolved automatically from the API key; if the key’s owner is not an admin/owner, the request is rejected.
The audit index retains at most 15 days. A single query cannot span more than 15 days, and it defaults to the last 15 days when no dates are provided. To keep history longer, export events into your own storage.
Use cursor pagination. Request the first page, then keep calling with the meta.next_cursor value from the previous response until it returns null. Cursor mode has no depth limit and won’t skip or duplicate rows.
The event data, old_state, and new_state objects are free-form. On the public API they are narrowed to a vetted allow-list, so provider internals, cross-system identifiers, internal billing state, and content-moderation flags are stripped. The dashboard and CSV export still show the full object.
No. Reading your own audit trail is included with your Enterprise plan at no additional cost.
500 requests per day per API key, plus a short-term burst cap. See Rate Limits for details.
  • Analytics API: credit consumption over time, plus team member, API key, group, and project discovery endpoints.