Audit log
The organisation's one timeline of who did what, from sign-in policy to API keys and data operations. What is recorded, what an entry holds, filtering it in the dashboard and the API, and how long it is kept.
The audit log is your organisation's record of who did what to what, and from where: members, API keys, connected apps, the AI agents and FurniOps staff. FurniOps sign-in and the API both write to it, and you read one timeline, newest first.
Read it under Settings › Audit log, or with
GET /v1/audit-events. It needs audit:read, which
owners and admins hold, and which an API key can hold.
What is recorded
| Area | For example |
|---|---|
| Members | A role changed, a member removed or left, invitations created, accepted and revoked, someone joining through single sign-on. |
| API keys | Keys created, updated, rotated, revoked and approved; reviews opened and dismissed; a leak reported. Access policies created, changed and deleted. |
| Sign-in and SSO | Sign-ins and failed sign-ins, confirming it is you, signing other sessions out, two-step verification turned off, a recovery code used, passkeys added and removed, the SSO connection and domains created, verified, changed and deleted. |
| Organisation | Settings changed, support access granted, an app connected. |
| OAuth apps | Apps created, updated and deleted; secrets rotated and revoked. |
| Data | Sources created, changed and given credentials, runs requested, files uploaded, mappings confirmed, category rules saved, exports started, source probes started, demand hints and variant checks. |
| AI agents | Agent settings changed, proposals applied (by a person, or by an agent on its own) and rejected. |
| Webhooks | Endpoints created, changed and deleted, secrets rotated, tests sent, failed deliveries recovered, a delivery resent. |
Actions are named <object>.<past-tense verb>, such as member.removed or api_key.rotated. The
list grows as FurniOps does; the dashboard's action filter offers the common ones.
An entry
{
"object": "audit_event",
"id": "aud_034XqBaL2mRLTZPXyRbaUi",
"action": "api_key.rotated",
"actor": { "kind": "user", "id": "usr_034XqBaL2mRLTZPXyRbaUa" },
"target": { "type": "api_key", "id": "key_034XqBaL2mRLTZPXyRbaUb" },
"ip": "203.0.113.0/24",
"user_agent": "Mozilla/5.0 …",
"request_id": "req_034XqBaL2mRLTZPXyRbaUq",
"data": {
"replacement": "key_034XqBaL2mRLTZPXyRbaUc",
"last_four": "a9Zq",
"overlap_hours": 24,
"old_ends_at": "2026-10-07T09:12:44Z"
},
"source": "identity",
"created_at": "2026-10-06T09:12:44Z"
}| Field | Meaning |
|---|---|
actor.kind | user (a member), api_key, client (a connected app), agent (an AI agent), staff (FurniOps support) or system (FurniOps itself). |
actor.id | The member's usr_…, the key's key_…, the app's client ID or the agent's name; null for the system. |
target | What it was done to, when there is one. |
ip | The address cut to its /24 (IPv4) or /48 (IPv6). The full address is never kept. |
request_id | The request that made the change, to find it in the request logs. |
data | Details of the action. Never a secret, a token or a key. When support acted for a member, acting_for names them. |
source | identity (sign-in, members, keys, SSO) or backend (the API's data). |
Filtering
In the dashboard, filter by action, by actor (members and keys are shown by name) and by whole days in UTC (a from and a to date, both included). The filters live in the URL, so a filtered view can be shared with another member.
With the API, action, actor (a public ID or a client ID), since (at or after) and until
(before) narrow the list; it pages with limit, starting_after and ending_before like every
list.
curl "https://api.furniops.com/v1/audit-events?actor=key_034XqBaL2mRLTZPXyRbaUb&since=2026-10-01T00:00:00Z" \
-H "Authorization: Bearer $FURNIOPS_API_KEY"How long it is kept
Entries are append-only: once written, an entry cannot be changed or deleted. They are kept for the life of the organisation and erased only when the organisation itself is deleted. The log covers both modes in one timeline.
Support access
How FurniOps support can see what one of your members sees, the limits on it, how every access is recorded in your audit log, and how an organisation blocks it.
Billing
How an organisation will pay for its plan and FurniOps AI credit. Billing is switched off today. What the billing API and Settings › Billing show, and how subscribing, changing plan, the card, invoices and credit work once selling starts.