Platform

Audit trail

Review who changed what in your Tenklo account.

The audit trail records control-plane activity in your Tenklo 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, with a default 1 year data retention. Contact us if you would like a demo.

View & export

When enabled for your account, the audit trail lives in the Tenklo 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:

FieldDescription
idA unique ID for the entry, useful when referring to one in a support request
occurredAtWhen the action happened
actorWho performed it — see Actors
viaOnly present when the action reached Tenklo through a Tenklo support session — see Tenklo support access
resource and actionWhat was done, for example connection + deleted
targetsWhat it was done to, such as a connection ID or a teammate's email
outcomesuccess, failure, or denied
scopeWhether the action applied to a single environment or to the whole account
environmentThe environment involved. Empty when scope is account, because the action was not tied to one
contextThe originating IP address and user agent, and the interface used: api covers both the dashboard and the REST API, mcp covers Tenklo's management MCP server
metadataDetail 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 resources and actions are:

ResourceActions
connectioncreated, updated, metadata_updated, refreshed, deleted
integrationcreated, updated, deleted
functiondeployed, upgraded, updated, deleted, variant_created, variant_deleted, variant_updated
syncenabled, disabled, paused, started, triggered, cancelled, frequency_changed, variant_created, variant_deleted
api_keycreated, updated, deleted
environmentcreated, updated, variables_changed, webhook_urls_changed, webhook_signing_key_rotated, deleted
memberinvited, invite_accepted, invite_declined, invite_revoked, removed, role_changed
teamupdated
userupdated
app_authlogin, logout, signup, password_changed, password_reset
mfaenrolled, enabled, disabled, verified, recovery_regenerated
billingplan_changed, trial_extended, details_changed, payment_method_added, payment_method_removed, spend_alert_changed, spend_alert_removed
audit_trailqueried, 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.

function.variant_updated records the requested enabled and frequency settings in its metadata. A frequency of null means the frequency override was reset. Omitted settings are not included.

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 for details.

Actors

ActorMeaning
userSomeone signed in to the Tenklo dashboard
api_keyA call authenticated with an API key. The entry includes the API key's name.
connect_sessionThe 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
anonymousTenklo 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_keyA connection created through the legacy public key flow. The key identifies your environment, not a person, so no end user is named

Tenklo support access

Tenklo staff may access your account to investigate a support request. Actions taken during such a session carry the via field, naming the Tenklo account that was acting, next to the actor the action was performed as. An entry without via was not reached through a Tenklo session.

via also carries the id of the individual operator, so two Tenklo people are distinguishable in your trail. It is an id and never a name or email: it identifies them to Tenklo, 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!

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 recordedExample
Reading connection credentialsGET /connection/{connectionId}
Reading records from TenkloGET /records
Deleting/pruning records in TenkloPATCH /records pruning
Setting or updating connection metadata via the APIPOST / PATCH /connection/metadata
Triggering a sync via the APIPOST /sync/trigger
Proxy requestsEvery call through /proxy
Action executionsPOST /action/trigger
Reading configurationListing or fetching connections, integrations, or functions

On this page