Audit trail & system log
Two separate logs: what changed in the business data – and what happened technically.
SimpleAct keeps two logs that are frequently confused. The audit trail answers "who changed which record, when and how" and is evidence. The system log answers "what happened in operations" and is a diagnostic tool. The difference is not cosmetic: only the audit trail is protected against retroactive alteration.
At a glance
- Included from
- All plans
- Where in the app
- Administration → Audit log / System log
- Output
- Change history with an integrity proof, system log export for SIEM
- API
- /api/v1/admin/audit-logs · /api/v1/admin/system-logs
Why the audit trail is a hash chain
A change log is only worth as much as the answer to one question: "how do we know nothing was altered after the fact?" That is why every audit entry carries a hash over its own content plus the hash of its predecessor. Every entry therefore seals the whole chain before it.
If an entry is later modified or removed, its hash no longer matches what the next entry expects – the chain breaks at a demonstrable point. You can run that verification yourself: for the history of a single record, or in one pass across every chain in your organization. The result is the statement that counts in an audit: unaltered or not, and if not, from where.
What an audit entry contains
| Field | Meaning |
|---|---|
| Actor | Who triggered the change – with role. For API access the API key is recorded as the actor, with the key’s name and ID; the user ID stays empty. |
| Action source | Whether the change came from the interface, the API or a system process. An API key is always recorded as "api" – that cannot be overridden by a header. |
| Action and event type | What was done – create, update, delete, export, approve. |
| Entity and record ID | What it happened to. This is also how chain verification for a single record is scoped. |
| Old and new value | The state before and after – field-level where applicable. That is the difference between "was changed" and "was changed to this". |
| Status and error message | Failed attempts are logged too. A log that only records successes hides precisely the interesting cases. |
| IP address, user agent, locale | The technical context of the access. |
| Hash and previous hash | The chaining that makes integrity verification possible. |
System log
The system log is the operations view. It can be filtered and exported – typically to feed a SIEM.
| Property | Values |
|---|---|
| Levels | ERROR, WARNING, INFO, DEBUG, TRACE |
| Sources | API, UI, SYSTEM, DATABASE, AUTH, MIDDLEWARE |
| Filters | Level, source, user, time range and further criteria. An unknown filter value is rejected rather than silently ignored. |
| Export | JSON or CSV, up to 10,000 entries, newest first. The response is always JSON: for CSV the text sits in the data field – not a file download. |
| Additional fields | Request ID, endpoint, HTTP method, status code and response time – enough to work a bug report without follow-up questions. |
API writes carry no person’s name
Records changed via an API key show a fixed technical identifier as creator or editor – not the person who created the key. That is deliberate: a key is not a person, and filing a machine change under a person’s name would make the audit trail claim something that did not happen. Which key it was is recorded in the audit trail.
Timestamps are UTC
All timestamps are kept in UTC and delivered as ISO 8601 with a trailing Z. When reconciling logs with other systems, convert on import – not on export.