Skip to navigation
Console and settings

Audit logs

A record of every administrative change made in your organisation.

The audit log is the history of administrative actions in your organisation: who changed what, and when. Use it to answer questions such as “who revoked this API key?”, “who approved this verification?” or “when did this role gain that permission?”. It is written for compliance leads preparing evidence and for admins investigating a change.

Where to find it

Open Organisation → Audit Logs in the console. Reading it requires the audit_logs:read permission, which every built-in role holds by default. Remove the key from a role in Settings → Roles & Permissions if some team members should not see it.

The log is scoped to your organisation. You never see another organisation’s entries, and nobody outside your organisation sees yours through this page.

What is recorded

An entry is written for every action that changes something. Reading a page or fetching a record is not logged, with a few exceptions where the read is itself a disclosure (for example, downloading a SAR report is recorded as sar.exported).

Each action has a stable, dotted name. The prefix tells you the area:

AreaExample actions
API keysapi_key.created, api_key.revoked, api_key.restrictions_updated
Webhookswebhook.created, webhook.updated, webhook.deleted, webhook.secret_rotated, webhook.redelivered
Team and rolesteam.invite_sent, team.invite_accepted, team.member_role_changed, team.member_removed, role.created, role.updated, role.deleted
Organisation and accountorganization.updated, organization.mobile_apps_updated, account.password_changed
Business onboardingkyb.profile_updated, kyb.document_added, kyb.submitted, kyb.appeal_submitted
Workflowsworkflow.created, workflow.published, workflow.unpublished, workflow.archived, workflow.version_restored
Verifications and sessionsverification.reviewed, verification.deleted, session.created, session.expired, spot_check.created, business_check.created
Customersentity.created, entity.updated, entity.deleted, entity.wallets_updated, entity.biometric_revoked
Screening, cases and reportsscreening.adjudicated, case.opened, case.assigned, case.disposed, sar.drafted, sar.filed
Rules and monitoringmonitoring.config_updated, monitoring.policy_published, fraud.rule_published, fraud.decision_overridden
Listsblocklist.entry_added, blocklist.entry_removed, face_list.entry_added, custom_list.created
Billingbilling.top_up_request.created, billing.threshold.updated, billing.payment_method.added, billing.auto_topup.resumed

Action names are a stable contract. New ones are added over time, but an existing name is not renamed or reused for something else, so you can filter and report on them safely.

Some entries are written by Toden rather than by a member of your team: automatic events such as an automatic top-up being paused, and actions Toden support takes on your account. A support action is recorded in your log with a support actor role and byPlatform: true in its metadata, so work done on your behalf is never hidden from you.

Search and filter

The table lists entries newest first, with four columns: When, Actor, Action and Summary.

ControlWhat it does
Search boxMatches the action name, the summary, the actor’s email address and the ID of the affected record. Not case sensitive
Action filterNarrows the list to one action. The options are the actions seen in the entries you have loaded
Page size10, 20, 50 or 100 entries per page

To find everything that happened to one record, paste its ID (for example a verification ID) into the search box.

What each entry holds

FieldMeaning
createdAtWhen the action happened
actorName, actorEmailThe person who acted, captured at the time. The entry stays readable if that person is later renamed or leaves
actorRoleThe name of the role they held when they acted
actionThe dotted action name
targetType, targetIdThe kind of record affected and its ID
summaryOne sentence describing the change
metadataStructured detail: IDs, the status before and after, the names of the fields that changed
ipAddress, userAgentWhere the request came from

What is deliberately not stored

Audit entries are designed to be safe to read and to share with an auditor.

  • No secrets. API keys, webhook signing secrets, passwords and tokens are never written. A key appears only as its name and prefix.
  • No identity data. ID numbers, document images, selfies and other captured media are not copied into the log. An entry refers to a verification or customer by ID.
  • No record contents. Metadata names the fields that changed and the status before and after, not the contents of a customer’s record.
  • No webhook payloads. Delivery payloads live with the delivery, under Developers → Webhooks.

Things to know

  • The log is append-only. There is no way to edit or delete an entry from the console or the API.
  • Entries outlive what they describe. Deleting a member, a key or a record does not remove the entries about it.
  • It covers both environments. The audit log is not split by Sandbox and Production. Where the environment matters, such as for an API key, it is stated in the summary and metadata.
  • Writing an entry never blocks the action. Most entries are written straight after the change succeeds. Entries for regulated actions (alert decisions, case outcomes, SAR drafting and filing) are committed together with the change itself and then delivered to the log, so they cannot be lost.
  • It is not your API request log. For individual API calls, timings and status codes, use Developers → Logs.