Audit Logs

The audit log records every admin action in your project, like creating an API key or adding a teammate. Entries are permanent.

It answers "who changed this, and when?" Typical moments you'll open it:

• A production API key was revoked and calls started failing. Who revoked it?
• A teammate left the company. What did they change before leaving?
• A security review asks you to prove who has had access to keys.

The audit log covers people managing your Livqeno project (in the dashboard or CLI). It does not record what your app's users do in calls or chats. For that, use webhooks and Observability.

Where to find it: dashboard → your project → Audit log.

Who can read it: owners and admins (they have audit:read). Developers can create API keys, but can't see who else created them. See Roles & Permissions.

What an entry looks like

{
  "publicId": "aud_SymceSuFMYAUvZbYOtxdSA",
  "projectId": "b357b46d-8fc9-4f9d-a5c2-cdfee6b30a9e",
  "environment": "PRODUCTION",
  "actorId": "32b1e402-9138-43af-b26d-a2f1b62f3535",
  "actorEmail": "dev@example.com",
  "action": "api_key.created",
  "resourceType": "api_key",
  "resourceId": "rvk_prod_y2KZHYFCezTE",
  "metadata": { "name": "backend" },
  "requestId": "req_9755fd8325d28074ed5ce6cc",
  "ipAddress": "203.0.113.7",
  "userAgent": "livqeno-cli/0.1.0",
  "createdAt": "2026-08-19T11:31:04.221Z"
}

Two useful fields:

• actorEmail is saved on the entry itself. You can still see who did something, even after that person's account is gone.
• requestId matches the x-request-id of the request that caused it. Use it to link an entry to a specific call or error. See Error Codes.

Actions that are recorded

The four room.* actions are the server moderation calls on a live room (remove, mute, change permissions, change metadata or attributes). They are made with an API key, so the actor is the key, not a person.

Filtering

These are dashboard endpoints: you call them with your developer login (the dashboard and CLI do this for you), not with a project API key. Add query parameters to narrow the list:

GET .../audit-logs?action=api_key.revoked
GET .../audit-logs?actorId={userId}
GET .../audit-logs?resourceId=rvk_prod_y2KZHYFCezTE
GET .../audit-logs?limit=200

• Results are newest first.
• Default 50 entries, maximum 200.
• An unknown action returns a 400. This way a typo never looks like "nothing happened".

Filter by resourceId to see the whole history of one thing. For example, the life of one API key:

[
  { "action": "api_key.revoked", "createdAt": "2026-08-19T14:02:11.004Z" },
  { "action": "api_key.created", "createdAt": "2026-08-19T11:31:04.221Z" }
]

What is never recorded

• Secrets. No API key secrets, webhook signing secrets, or passwords. A key's public id is recorded. Its secret was shown once and never stored.
• Chat messages. Message content is not an admin action.
• New values on updates. project.updated records which fields changed, not what they changed to.

Entries can't be changed

No endpoint can edit or delete an entry. Not even an admin can change the log: the database itself refuses to update or delete audit entries.

The one exception is permanent project deletion. When a project you scheduled for deletion is removed, its audit log is removed with it.

If an entry fails to save

Your request still succeeds, and the entry is not lost. We keep it and retry until it is written, with its original time. Every failed write is logged and counted on our side, so we notice when one happens.

Why the request still succeeds: by the time the entry is written, the action (say, creating a key) is already done. Reporting a failure would make you retry, and you'd end up with two keys.

Next steps

• Roles & permissions: decide who on your team can do each action recorded here.
• Security: how credentials are protected.