# Using audit logs

Source: https://help.didit.me/account-organization/audit-logs
Updated: 2026-10-29

Every API request in your organization is recorded for 365 days: who, what, when, from where and under which application. Check it first to see what happened.

Every API request in your organization is logged automatically and kept for **365
days** - from the console, your integration, and your teammates alike. Find it
under **Settings → Audit log**. Each decision the Investigator takes on its own is
recorded there too, under **The Investigator**.

[Video: The audit log - Didit Academy](https://www.youtube.com/watch?v=MkULotdgz2o&t=31)

## What's recorded

![Audit logs in the Didit console showing API activity with timestamps and status codes](https://help.didit.me/screenshots/audit-logs-light.webp)

*Every API request in the organization, kept for 365 days.*

Every request made to the Didit platform within your organization, whatever made it. Each entry carries:

| Field | Detail |
|---|---|
| **Timestamp** | When the request was made |
| **User** | Who did it: the member who made the request; for an API-key request, the key's name with an **API key** tag; **Didit** for what Didit does on its own; and **The Investigator** for a decision it takes on its own |
| **Method** | GET, POST, PUT, DELETE |
| **Path** | The endpoint that was called |
| **Status** | The HTTP response status |
| **IP address** | Where the request came from |
| **Application** | Which application it belonged to |

Logs are retained for **365 days** and then deleted automatically.

A redesigned audit log, which describes each change in words and can export what you're looking at, is rolling out. Until it reaches your organization, the page shows the request log described here.

## What it's actually for

Four situations where it's the right tool:

- **"Who changed this workflow?"** A flow behaving differently than yesterday usually has an edit behind it, and the log names who made it.
- **Investigating an incident.** Tracing exactly what was accessed, by whom, from which address, in what order.
- **Debugging an integration.** Seeing the requests your own code actually made, rather than the ones you believe it made - including the ones that 4xx'd.
- **Evidencing access control.** Showing an auditor that access to verification data is attributed and reviewable.

## Filtering

Filter by user (a member, an API key, Didit or The Investigator), endpoint, or date range to narrow a long list. When you're investigating something specific, start from the timestamp and work outwards - a request rarely happens alone, and the calls immediately around it usually tell the story.

## API-key requests are attributed to the key, not a person

An API-key request has no person to attribute it to, so it shows the key's name instead. That's the honest representation - the platform genuinely doesn't know which of your services or engineers made the call.

The practical consequence: a single key shared across several services makes an incident materially harder to investigate. If attribution matters to you, give each service its own key. See [managing your API keys](https://help.didit.me/account-organization/api-keys).

## The Investigator's own decisions are attributed to the Investigator

When the Investigator decides on its own, within the autonomy you gave it, the entry names **The Investigator**, not a person or a key. That covers each decision it takes: approving or declining a session or asking the user to resubmit, setting a transaction's status, and resolving a case, escalating it or requesting information on it. Each of these entries links to the Investigator report behind the decision, so you can see what it found and which rule of your policy it applied.

When a person decides on an Investigator report, accepting its recommendation or overriding it, the entry is attributed to that person, like any other change they make. The Investigator's full trail, with its reports, questions and guardrails, stays in its own **Activity** log. See [Control and oversee the Investigator](https://help.didit.me/investigations/investigator-automation-and-oversight).

## What's in the log, and what isn't

The log records **activity** - who called what, when, from where, and what status came back. It is a metadata trail, not a copy of the verification data.

If you need to know whether customer personal data appears in these entries - a question that comes up during data-protection reviews - get the answer from your Didit contact and record it, rather than inferring it from a help page. It's exactly the kind of statement your own DPIA will be expected to evidence.

## Who can see it

Audit log access follows role. **Compliance Officer** includes it; **Reader** does not have broad access. Owners can grant it to a custom role. See [inviting team members and setting roles](https://help.didit.me/account-organization/team-members-and-roles).

Removing a teammate doesn't remove their history from the log - which is the point. A trail you can edit isn't a trail.

## Exports and reports are logged too

Generating a session PDF or a CSV export is an API call, so it appears here with who made it. That's useful when you need to show that access to verification evidence is controlled rather than open. See [downloading a verification report](https://help.didit.me/verification-sessions/download-verification-report).

## If you need longer than 365 days

The retention is fixed at 365 days. If your obligation is longer, export what you need on a schedule and keep it in your own system - the same pattern as retaining session evidence yourself. Deciding the required period is a compliance decision for your team; don't design around an assumption.

> **Note:** Audit-log retention and **verification-data** retention are separate settings.
> Configuring a short retention window for session data doesn't shorten the audit
> log, and the reverse is also true. See
> [how Didit protects your users' data](https://help.didit.me/data-privacy/how-didit-protects-data).