> ## Documentation Index
> Fetch the complete documentation index at: https://docs.reconlayer.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Audit

> The global, filterable audit trail across cases, imports, and admin actions.

The **Audit** page (header: "Global audit trail", description "A single event history layer for cases, imports, integrations, and admin actions.") gives operators and compliance teams one searchable view of every `AuditEvent` recorded for the organization.

<Note>
  The audit trail is append-only and immutable. Every significant action — submitting an expectation, processing an import, linking evidence to a case, or changing a case's status — is recorded as an `AuditEvent` and can never be edited or deleted after the fact.
</Note>

## Data source

The table is loaded from [List audit events](/api-reference/dashboard/list-audit-events):

```
GET /v1/audit-events
```

Each `ReconciliationAuditEvent` returned includes:

| Field             | Description                                |
| ----------------- | ------------------------------------------ |
| `id`              | Unique event ID                            |
| `eventType`       | The type of action recorded (see below)    |
| `actor`           | Who or what performed the action           |
| `message`         | A human-readable description, if available |
| `occurredAt`      | Timestamp                                  |
| `paymentIntentId` | Linked `PaymentIntent`, if applicable      |
| `caseId`          | Linked `ReconciliationCase`, if applicable |
| `rawRecordId`     | Linked `RawRecord`, if applicable          |
| `importBatchId`   | Linked `ImportBatch`, if applicable        |
| `payload`         | Additional structured detail for the event |

This endpoint requires the `audit_view` or `logs_view` permission and is signed-in-user only (it cannot be called with an API key).

## Event types

Event types observed in the system include (non-exhaustive):

| `eventType`                      | Recorded when                                                       |
| -------------------------------- | ------------------------------------------------------------------- |
| `payment_intent.created`         | A new `PaymentIntent` is created                                    |
| `payment_intent.replayed`        | A `PaymentIntent` is recreated idempotently from a repeated request |
| `payment_intent.import_created`  | A `PaymentIntent` is created from an import row                     |
| `payment_intent.import_replayed` | An import-sourced `PaymentIntent` is recreated idempotently         |
| `import.batch.created`           | An `ImportBatch` is created                                         |
| `import.batch.completed`         | An `ImportBatch` finishes processing                                |
| `import.batch.failed`            | An `ImportBatch` fails during processing                            |
| `case.evaluated`                 | The matching engine evaluates a case against available evidence     |

The Event type filter dropdown is populated dynamically from the distinct `eventType` values present in the currently loaded events, so it will reflect whatever event types your organization has actually generated.

## Table columns

| Column                 | Source            | Notes                                                      |
| ---------------------- | ----------------- | ---------------------------------------------------------- |
| Event type             | `eventType`       | Shown as a badge, colored by source (case vs. import)      |
| Actor                  | `actor`           | The user, API key, importer, or system process responsible |
| Related case           | `caseId`          | Links to `/dashboard/cases/{caseId}` when present          |
| Related payment intent | `paymentIntentId` | Shown as-is when present                                   |
| Message                | `message`         | Human-readable description                                 |
| Occurred time          | `occurredAt`      | Formatted timestamp                                        |

## Filters

The filter bar above the table supports:

* **Event type** — dropdown populated from observed event types, or "All types"
* **Actor** — free-text search (e.g. `api`, `webhook`, `importer`)
* **Case ID** — search by `caseId`
* **Payment intent ID** — search by `paymentIntentId`
* **Start date** / **End date** — restrict to a date range

All filters are reflected in the page's URL query parameters, so a filtered view can be bookmarked or shared. A **Reset filters** action clears all of them at once.

## Investigating a case end-to-end

Because every audit event can reference a `caseId` and/or `paymentIntentId`, the Audit page lets you reconstruct the full lifecycle of a single transaction: when the expectation was created, when each piece of evidence arrived, when the matching engine evaluated it, and any subsequent status changes — all from one filtered view. The same `caseId`-scoped events also appear on the **Audit Timeline** tab of the [case detail page](/dashboard/cases#case-detail).

## From here

<CardGroup cols={2}>
  <Card title="List audit events" icon="code" href="/api-reference/dashboard/list-audit-events">
    Query the audit trail directly, including by `importBatchId`.
  </Card>

  <Card title="Cases" icon="briefcase" href="/dashboard/cases">
    View a case's audit timeline alongside its evidence and verdict.
  </Card>

  <Card title="Overview" icon="gauge" href="/dashboard/overview">
    See aggregate operational metrics derived from the same underlying activity.
  </Card>

  <Card title="Developers" icon="code" href="/dashboard/developers">
    See a condensed activity feed driven by the same audit events.
  </Card>
</CardGroup>