The audit trail
Everything done in your organisation, and every attempt to sign in to it, recorded as it happens and chained so that a later change cannot pass unnoticed. It is at Audit trail in the side bar.
What is recorded
| Trail | What it holds |
|---|---|
| What was done | Actions against the product: a template created, a version activated, an API key issued or revoked, settings changed. Who did it, what they did it to, and when. |
| Who signed in | Sign-ins, and sign-ins that failed — including attempts against an address that has no account, which is exactly the pattern a trail exists to show. |
A signature has its own trail, kept with the envelope rather than here: every view, code sent, signature and decline, with the address and the browser. It appears on the document's own page and travels in the evidence bundle.
Why it can be relied on
Every entry carries the fingerprint of the entry before it. Change one row and its own fingerprint no longer matches; delete one and the next row points at something that is not there; reorder two and both break.
Press Check the chain and the whole thing is walked, oldest to newest. It reports either that it verifies and how many entries were checked, or the first break and where it is — only the first, because after one break everything later is unverifiable anyway and a list of two hundred consequences hides the one cause.
It is deliberately not run on every page load: it reads the whole chain, and a page that gets slower as the trail grows is a page nobody opens.
What this proves, precisely. It proves that nobody has edited, removed or reordered an entry since it was written. It is tamper-evidence, not tamper-proofing: somebody with direct access to the database server could in principle recompute an entire chain. Two things stand in the way: the trails are append-only in the database itself, so an ordinary edit or deletion of an entry is refused; and once a day the newest link of each chain is sent off the server by email, so a chain rewritten from the start no longer contains a link that was copied out before it. Entries written after the last copy are covered by the next day's.
The date has a third witness that is not ours. Once a day the fingerprint of the newest link (and nothing else: no entry, no name) is sent to a time-stamping authority (RFC 3161) and the signed answer is kept and copied with the daily backup. Check the chain then also says whether every stored timestamp still matches a link the chain contains. It is a free, non-qualified authority: good evidence of when the chain had that link, not a qualified timestamp with a legal presumption of date.
What a change used to be
A change to an existing value records what it was and what it became:
the Change column of the page, and the before and
after columns of the export (as JSON, only the fields that changed).
The old value is part of the entry's fingerprint, so it cannot be altered afterwards
without breaking the chain; an entry written before this existed has no such columns and
verifies as it always did.
Nothing sensitive is written there. A password, a token, a key or a secret is
never recorded, only the fact that it changed; a person's details (a phone number, an
address, a name, a free-text note or reason) are shown as [personal data];
a long value is cut. A change made by creating or deleting something records that
event, not a before and after.
Answering a question with it
An auditor rarely browses. They ask a question — what did this person do between these dates?, show me every change to this template — so the page is a filter and an export rather than a dashboard.
- Containing matches a name, an action, an entity or an address.
- From and To take whole days, and To includes the day you typed.
- Results are newest first, a hundred to a page.
Exporting it
Export what is shown gives you a CSV of every row the filter matches — not just the page you are looking at. A file that quietly stopped at a hundred would be evidence with a hole in it that nothing declared, and somebody would hand it over without reading.
The export is oldest first, because that is the order things happened in and a reviewer reads forwards. Two columns travel with it that are worth keeping:
| Column | Why it matters |
|---|---|
chain_index | The entry's position in the chain. Gaps are meaningful. |
entry_hash | The fingerprint. This is what lets somebody check the file against the live trail later — without it the export is a list of claims, and with it a list that can be verified. |
How long it is kept
As long as the records it describes. Signature evidence is kept for ten years by default and your organisation can choose less, never more; documents themselves expire after a year. When evidence is finally swept, the entries go with it and the fact that something existed and was not altered survives.
Who can see it
Your organisation's coordinators — not other customers, and not your own ordinary users. Our platform operators can open it as well when they work inside your console to support you.
Times on the page are written in your organisation's locale. The From and To filter count whole days in that zone, and the CSV export writes every time in it as ISO 8601 with its offset — the same instant as the API's UTC, so a file can be compared with its answers without guessing a zone.
The trail names colleagues and the addresses that tried to sign in, which is not general reading.