> ## Documentation Index
> Fetch the complete documentation index at: https://nango.dev/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Audit trail
> Review who changed what in your Nango account.
The audit trail records **control-plane** activity in your Nango account — the operations that configure it and manage who can reach it: connection changes, integration settings, teammate roles, sign-ins.
Each entry captures the actor, the action, the affected resource, and the outcome, so you can answer "who did this, and when" during an incident or a compliance review.
Entries are immutable: Nango never edits or deletes one before its retention period ends.
## Availability
The audit trail is available on the [Enterprise plan](https://nango.dev/pricing), with a default 1 year data retention. [Contact us](https://nango.dev/demo) if you would like a demo.
## View & export
When enabled for your account, the audit trail lives in the Nango dashboard under **Audit trail**, in the menu behind your profile. It covers all activity in your account, across all environments.
### Exporting to CSV
You can export audit trail entries as a CSV, filtered by time window, resource, and action.
A single export returns at most 50,000 entries, most recent first. If your selection holds more, the download still succeeds and the dashboard tells you it was truncated. Narrow the window, or contact support for help with a larger export.
## What is recorded
Each entry records:
| Field | Description |
| ----------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `id` | A unique ID for the entry, useful when referring to one in a support request |
| `occurredAt` | When the action happened |
| `actor` | Who performed it — see [Actors](#actors) |
| `via` | Only present when the action reached Nango through a Nango support session — see [Nango support access](#nango-support-access) |
| `resource` and `action` | What was done, for example `connection` + `deleted` |
| `targets` | What it was done to, such as a connection ID or a teammate's email |
| `outcome` | `success`, `failure`, or `denied` |
| `scope` | Whether the action applied to a single environment or to the whole account |
| `environment` | The environment involved. Empty when `scope` is `account`, because the action was not tied to one |
| `context` | The originating IP address and user agent, and the interface used: `api` covers both the dashboard and the REST API, `mcp` covers Nango's management MCP server |
| `metadata` | Detail specific to the action, such as whether a sync run was a full refresh, or the filters an export used |
The audit trail covers the main control-plane operations related to connections, integrations, functions, syncs, API keys, environments, team membership, authentication, and billing. The recorded `resource`s and `action`s are:
| Resource | Actions |
| ------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- |
| `connection` | `created`, `updated`, `metadata_updated`, `refreshed`, `deleted` |
| `integration` | `created`, `updated`, `deleted` |
| `function` | `deployed`, `upgraded`, `deleted` |
| `sync` | `enabled`, `disabled`, `paused`, `started`, `triggered`, `cancelled`, `frequency_changed`, `variant_created`, `variant_deleted` |
| `api_key` | `created`, `updated`, `deleted` |
| `environment` | `created`, `updated`, `variables_changed`, `webhook_urls_changed`, `webhook_signing_key_rotated`, `deleted` |
| `member` | `invited`, `invite_accepted`, `invite_declined`, `invite_revoked`, `removed`, `role_changed` |
| `team` | `updated` |
| `user` | `updated` |
| `app_auth` | `login`, `logout`, `signup`, `password_changed`, `password_reset` |
| `mfa` | `enrolled`, `enabled`, `disabled`, `verified`, `recovery_regenerated` |
| `billing` | `plan_changed`, `trial_extended`, `details_changed`, `payment_method_added`, `payment_method_removed`, `spend_alert_changed`, `spend_alert_removed` |
| `audit_trail` | `queried`, `exported` |
`connection.metadata_updated` and `sync.triggered` are recorded for actions taken in the dashboard. The equivalent API endpoints — `POST` / `PATCH /connection/metadata` and `POST /sync/trigger` — are data plane operations and are not recorded; see [Limitations](#limitations).
Secrets, such as API keys and passwords, are stripped from audit log entries.
Reads are generally not recorded. Listing connections, fetching an integration, or opening a page in the dashboard leaves no entry. Our audit trail is designed to answer "what changed", not "what was looked at". Queries to the audit trail are an exception and logged with the actions listed above.
The audit trail currently does not cover data plane operations, such as reading connection credentials or fetching sync records. See [Limitations](#limitations) for details.
## Actors
| Actor | Meaning |
| ----------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `user` | Someone signed in to the Nango dashboard |
| `api_key` | A call authenticated with an API key. The entry includes the API key's name. |
| `connect_session` | The end user who completed a Connect flow, identified by the end-user ID you supplied when creating the session, and their email if you supplied one |
| `anonymous` | Nango knows an attempt was made but cannot name who made it — a rejected sign-in, for example. The email in the request was never verified, so it appears as the target rather than the actor |
| `public_key` | A connection created through the [legacy public key flow](/docs/guides/platform/migrations/migrate-from-public-key). The key identifies your environment, not a person, so no end user is named |
### Nango support access
Nango staff may access your account to investigate a support request. Actions taken during such a session carry the `via` field, naming the Nango account that was acting, next to the `actor` the action was performed as. An entry without `via` was not reached through a Nango session.
`via` also carries the id of the individual operator, so two Nango people are distinguishable in your trail. It is an id and never a name or email: it identifies them to Nango, not to you. Ask us and we can tell you who it was.
## Limitations
We can expand audit trail coverage on request. If you need items logged that aren't covered today, please [reach out](https://nango.dev/demo)!
The audit trail currently covers the control plane, but not the **data plane**: API requests used to work with integrations and exchange data with external APIs.
For example, the following activities are not covered:
| Not recorded | Example |
| --------------------------------------------------- | ----------------------------------------------------------- |
| Reading connection credentials | `GET /connection/{connectionId}` |
| Reading records from Nango | `GET /records` |
| Deleting/pruning records in Nango | `PATCH /records` pruning |
| Setting or updating connection metadata via the API | `POST` / `PATCH /connection/metadata` |
| Triggering a sync via the API | `POST /sync/trigger` |
| Proxy requests | Every call through `/proxy` |
| Action executions | `POST /action/trigger` |
| Reading configuration | Listing or fetching connections, integrations, or functions |