Audit log
A tamper-resistant record of what your team and your API keys did in your organization, with filters and CSV export.
Every change made in your organization leaves an entry: who did it, what they did, to what, when, from which address, and whether it worked. Owners and admins read it in the dashboard under Settings, Audit log, or export it as a CSV file.
What is recorded
| Area | Examples |
|---|---|
| Sign-in | auth.login, auth.login_failed (wrong password for a real account), auth.password_change, auth.password_reset, auth.oauth_link, auth.oauth_unlink, auth.signup, auth.mfa_enable, auth.mfa_disable, auth.mfa_failed (a wrong second-step code), auth.mfa_recovery_used, auth.mfa_recovery_regenerate |
| People | member.role_change (with the old and new role), member.remove, invitation.create, invitation.revoke, invitation.accept |
| API keys | api_key.create (with its scopes, address ranges and expiry), api_key.revoke |
| Agents | agent.create, agent.update, agent.publish, agent.delete, functions, knowledge, MCP servers |
| Numbers and trunks | phone_number.create, .update, .assign, .delete, .inbound_secret_rotate, sip_trunk.* |
| Webhooks | webhook.create, .update, .delete, .secret_rotate, .delivery_resend |
| Contacts and campaigns | contact.*, contact_list.*, do_not_call.*, campaign.start, .pause, .cancel, contact.data_erase |
| Billing | billing.auto_recharge_update, billing.checkout_start |
| Data | org.retention_update, call.delete, audit.export |
Reads are not recorded, and neither are the calls themselves: a call is in your call log. Nothing that was refused for being invalid is recorded either, but a request refused for lack of permission is, with the outcome denied. That includes a scoped API key reaching for something outside its scopes.
An entry
Each entry has:
- actor: a
user(with their email), anapi_key(with the key's name and ID), orservice. - action and target: for example
agent.publishon the agent's ID. - outcome:
ok,deniedorfailed. - ip, user_agent and request_id: where it came from, and the
x-request-idyou can quote to support. - meta: extra facts such as
from_roleandto_role. Secrets, request bodies and query strings are never stored.
Reading it
Open Settings, Audit log in the dashboard. You can filter by action (a full name, or a prefix ending in a dot such as agent.), actor (name, email or ID), target, outcome and date range. Results are newest first.
Export downloads the filtered rows as CSV. The file holds up to 50,000 rows and says so when there were more; narrow the dates for the rest. Cells that a spreadsheet would read as a formula are prefixed with an apostrophe.
Only owners and admins signed in as people can read the log. An API key cannot, whatever its scopes.
What to rely on, and what not to
- There is no way to change or delete an entry through the API, and the table refuses updates and deletes at the database. A database administrator can still drop that protection, so this is not evidence against someone who controls the database.
- An entry is written just after the action completes, in its own transaction. If the database write fails at that moment the action has already happened and the entry is lost; Dialgem counts and alerts on this (
audit_write_failures_total) but it is not a guarantee of one entry per action. - Dialgem staff actions on your organization (for example a support session) are recorded in a separate staff log, not in yours.
- Entries are kept until the organization is deleted. They are not covered by data-retention settings.
- The address recorded is only as trustworthy as the proxy in front of Dialgem; see API key scopes.