Privacy: the audit trail

Every action in a workspace (signing in, changing a dispute, creating a key or a webhook, exporting data) is recorded as an audit event with:

• what happened, when, and whether it succeeded or was refused;
• who did it: the member's or synthetic account's id and username (the workspace owner's e-mail address), or the API key's id and name;
• the request: its id, the correlation id the caller chose, whether it came from the portal or the API, the route, and the client's IP address and browser user agent (cut to 256 characters).

Passwords, verification and MFA codes, tokens, API keys, signing secrets, signed download links and other people's e-mail addresses are removed before an event is stored.

We keep the trail on the basis of legitimate interest (Article 6(1)(f) GDPR): to secure accounts and API keys, to let workspace owners see who did what in their workspace, to investigate abuse and incidents, and to let customers' own automated tests confirm what happened. IP addresses and user agents serve the security purposes: spotting a leaked key or a sign-in from an unexpected place.

• The workspace owner sees the full trail of their workspace, including IP addresses and user agents.
• API keys may read the trail with the audit.readscope but never see IP addresses, user agents, members' e-mail addresses or sign-in details (details).
• No workspace can read another workspace's trail.

180 days.A nightly job deletes older events, IP addresses and user agents included. Resetting a workspace's sandbox data does not delete its trail. Events cannot be edited; the only other deletion is an erasure request, for which we replace a person's identifiers in the trail with a pseudonym.

Sign-out is not recorded: it only clears the portal's cookies in your browser.