> Toden documentation. For the full index fetch /llms.txt. Every page is available as Markdown by appending .md to its URL. Identity verification uses /api/kyc, Risk Intelligence uses /api/v1; they are separate contracts with different error shapes. Never invent an endpoint, field or enum value: read the API reference page for the operation first. # Audit logs > What the Toden audit log records, who can read it, how to search and filter it, what each entry holds and what is deliberately left out. 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: | Area | Example actions | | ---------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | | API keys | `api_key.created`, `api_key.revoked`, `api_key.restrictions_updated` | | Webhooks | `webhook.created`, `webhook.updated`, `webhook.deleted`, `webhook.secret_rotated`, `webhook.redelivered` | | Team and roles | `team.invite_sent`, `team.invite_accepted`, `team.member_role_changed`, `team.member_removed`, `role.created`, `role.updated`, `role.deleted` | | Organisation and account | `organization.updated`, `organization.mobile_apps_updated`, `account.password_changed` | | Business onboarding | `kyb.profile_updated`, `kyb.document_added`, `kyb.submitted`, `kyb.appeal_submitted` | | Workflows | `workflow.created`, `workflow.published`, `workflow.unpublished`, `workflow.archived`, `workflow.version_restored` | | Verifications and sessions | `verification.reviewed`, `verification.deleted`, `session.created`, `session.expired`, `spot_check.created`, `business_check.created` | | Customers | `entity.created`, `entity.updated`, `entity.deleted`, `entity.wallets_updated`, `entity.biometric_revoked` | | Screening, cases and reports | `screening.adjudicated`, `case.opened`, `case.assigned`, `case.disposed`, `sar.drafted`, `sar.filed` | | Rules and monitoring | `monitoring.config_updated`, `monitoring.policy_published`, `fraud.rule_published`, `fraud.decision_overridden` | | Lists | `blocklist.entry_added`, `blocklist.entry_removed`, `face_list.entry_added`, `custom_list.created` | | Billing | `billing.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. > **Note** > > 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**. | Control | What it does | | ------------- | --------------------------------------------------------------------------------------------------------------------- | | Search box | Matches the action name, the summary, the actor's email address and the ID of the affected record. Not case sensitive | | Action filter | Narrows the list to one action. The options are the actions seen in the entries you have loaded | | Page size | 10, 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 | Field | Meaning | | ------------------------- | -------------------------------------------------------------------------------------------------------------- | | `createdAt` | When the action happened | | `actorName`, `actorEmail` | The person who acted, captured at the time. The entry stays readable if that person is later renamed or leaves | | `actorRole` | The name of the role they held when they acted | | `action` | The dotted action name | | `targetType`, `targetId` | The kind of record affected and its ID | | `summary` | One sentence describing the change | | `metadata` | Structured detail: IDs, the status before and after, the names of the fields that changed | | `ipAddress`, `userAgent` | Where 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**. ## Related * [Roles and permissions](/get-started/console/roles-permissions) * [API keys](/get-started/console/api-keys) * [Data retention](/get-started/console/data-retention) * [Manage records](/user-verification/server-api/manage-records)