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

# Change history

> Trace an edit back to the person who made it.

Connect records the edits made to your data: who made them, the values before and after, and when.

<Frame>
  <img src="https://mintcdn.com/spirii-7457b714/Hq2YBNx3n8oQoC1s/images/components/change-history.png?fit=max&auto=format&n=Hq2YBNx3n8oQoC1s&q=85&s=c10879654fb6aa8a0181640578386d95" alt="The Change history log tab on a location in Spirii Connect, listing field-level edits with columns for date, who changed it, what was changed, and the new and old values" width="2950" height="1878" data-path="images/components/change-history.png" />
</Frame>

## Overview

Why a tariff changed, who removed a location from a voucher group, when a price was last edited: those questions come up after the fact, and Connect logs the changes as they happen.

Two surfaces reach that record.

<CardGroup cols={2}>
  <Card title="Change history log" icon="history">
    A tab in Connect on locations, voucher groups, and tariffs, showing field-level edits in place.
  </Card>

  <Card title="Audit log API" icon="code">
    The same records, filterable by user, address, record type, event, and date range.
  </Card>
</CardGroup>

## Change history in Connect

Locations, voucher groups, and tariffs each carry a **Change history log** tab, listing the edits made to that record.

### What a row shows

| Column         | What it shows              | Example                  |
| -------------- | -------------------------- | ------------------------ |
| Timestamp      | When the change was made   | `14 Jul 2026, 09:12`     |
| Field          | Which field changed        | `Base price`             |
| User           | Who made the change        | `lena.weber@example.com` |
| Previous value | What the field held before | `0.42`                   |
| New value      | What it holds now          | `0.45`                   |

Changes are attributed to the signed-in user who made them. Where an operator is impersonating a customer, the row names the operator's own user rather than the customer.

The tab is scoped to the record in front of you, so a location's history covers the location's own fields. Record creation, deletion, and association events are reachable through the API rather than here.

## The audit log API

[`GET /v2/audit-logs`](/api-reference/audit-logs/fetches-a-list-of-audit-logs) returns the recorded changes, including the event types and record types the Connect view does not surface.

### What a change record contains

| Field                 | What it records                                                    |
| --------------------- | ------------------------------------------------------------------ |
| User                  | The email address and ID of the user who made the change           |
| IP address            | The address the change was made from                               |
| Endpoint              | The endpoint that was called                                       |
| Record type           | What kind of record changed, such as a location or a voucher group |
| Record ID             | Which record changed                                               |
| Event                 | What happened to it                                                |
| Before and after      | The field values as they were, and as they became                  |
| Operator and customer | The account the acting user belongs to                             |
| Timestamp             | When the change was recorded, in UTC                               |

### Event types

| Event           | Meaning                                                                     |
| --------------- | --------------------------------------------------------------------------- |
| `created`       | A record was created. The before values are empty                           |
| `updated`       | One or more fields changed                                                  |
| `deleted`       | A record was deleted. The after values are empty                            |
| `associated`    | A record was linked to another, such as a location added to a voucher group |
| `disassociated` | A link between two records was removed                                      |

On an association event, the record also names the type of record on the other end of the link.

### Filtering

Filters cover the questions an investigation usually starts from:

* **Who** — by user email or user ID
* **Where from** — by IP address
* **What** — by record type, record ID, or event type
* **When** — a date range, with cursor pagination for large result sets

Each entry carries the before and after values, so the API answers what changed rather than only that something did.

## What is covered

Change history is the record of edits made in Connect. Each entry accounts for one change, with the user, the values, and the timestamp behind it.

Its scope is those edits. Updates written programmatically through the public API are separate, so where changes are automated your own systems hold the record of them.

Charger-level activity is separate too. Actions and configuration changes on a charge box, and the settings a driver adjusts on their own residential charger, are not change-history events. Read a record's entries as the account of its Connect activity.

## Dependencies & limitations

* **Change history covers edits made in Connect.** Updates through the public API are separate.
* **The Connect view covers three record types.** Locations, voucher groups, and tariffs. The API reaches the rest.
* **The Connect view shows edits only.** Record creation, deletion, and association events are in the API rather than the tab.
* **Charger-level activity is separate.** Actions and configuration changes on a charge box are not change-history events.
* **No retention window applies.** Change records are not aged out on a schedule, so history reaches back as far as the record itself.

## Related

To see who is able to make changes in the first place, start with the roles you have granted.

<CardGroup cols={2}>
  <Card title="Team access" icon="lock" href="/capabilities/account/user-management">
    The roles that decide who can change what.
  </Card>

  <Card title="Impersonation" icon="user-check">
    How changes are attributed when acting in a customer's context.
  </Card>

  <Card title="Data protection" icon="shield">
    How personal data is handled, retained, and removed.
  </Card>

  <Card title="Audit logs API" icon="code">
    Endpoint reference, parameters, and response schema.
  </Card>
</CardGroup>
