Audit Logs

Audit Logs give you a record of the changes made inside your SquawkVoice workspace — who changed what, when, and from where. Use them for compliance reviews, incident investigation, and change tracking.

​

What Gets Logged

Most create, update, and delete changes to the resources below are recorded automatically, and so is each completed publish of an agent and each time one of its versions is made active, renamed or deleted. Audit Logs also capture billing events. No configuration is required — logging is always on.

​

Resource Types

The Entity Type column in the log table shows each resource’s internal name, listed here beside the name you see in Studio.

​

Publishes

A completed publish of an agent is recorded as a PUBLISH entry. It shows the agent as the Entity Name, assistant as the Entity Type and whoever published as the Actor. A publish made with an API key shows the key’s creator. Under the Entity Name it shows the version the publish created, such as V29 or V29 · Spring prices, and the same version appears as Version in the entry’s details. Publishes from before agent versions existed show no version. A publish that fails leaves no entry. Select the entry to open Published Changes, which lays out what went live, section by section against the version it replaced, as Review Changes does before you publish. See Publishing Your Agent. Changes to an agent’s versions are recorded as entries for the same agent, each with the version it is about under the Entity Name and as Version in the details:

• ACTIVATE_VERSION — someone made a version active (see Make an Earlier Version Live). Its details show Changes when this version went live, which compares the version that was live before (PREVIOUS LIVE) with the one that was made live.
• RENAME_VERSION — someone renamed a version. Its Payload records the name before and after.
• DELETE_VERSION — someone deleted a version.

The version is shown with its name as it is now, so renaming a version changes how its earlier entries read, and once a version is deleted its entries read, for example, V7 (deleted). The Action dropdown has no entry for RENAME_VERSION or DELETE_VERSION; those entries appear under All Actions.

​

Billing Events

Billing entries show Plan (subscription events) or Account (credit and auto top-up events) as the Entity Type, and the plan or account name as the Entity Name. They have no IP address. The Action dropdown has no entry for UNSUBSCRIBED_FROM_PLAN; those entries appear under All Actions. The dropdown does list Plan Changed, but no entries of that type are recorded today.

---

​

Viewing Audit Logs

Open Manage → Audit Logs to view the log for your workspace. Logs are displayed in reverse chronological order, newest first, and more rows load as you scroll. The page opens on Last 7 Days, so older entries stay hidden until you choose a longer range. Each row shows:

​

Audit Log Details

Click any row, or focus it and press Enter, to open the Audit Log Details panel at the side of the page. It shows:

• Event Overview — the date, actor, action, entity type, entity name, Version (on an entry about an agent version), Entity ID (with a copy button), IP address and HTTP method.
• Request URL — the address the change was sent to.
• Payload — the data recorded for the event, as JSON. For a change, this is what was sent with it, not a before-and-after comparison.
• Published Changes — on a PUBLISH entry, in place of Payload: the changes that went live, laid out in the sections Review Changes uses, each against the version it replaced. When a publish changed so much that the comparison was too large to store, this reads “This diff was too large to store in full (N bytes) and was truncated. Diff exceeded 200000-byte limit for audit storage”, and when no comparison was recorded it reads “No diff was recorded for this publish.”
• Changes when this version went live — on an ACTIVATE_VERSION entry, in place of Payload: what changed when that version became the live one, laid out in the same sections against the version that was live before. It shows the same “too large to store” message as a publish when the comparison was too large, and reads “No diff was recorded for this activation.” when none was recorded.

Entity Name, HTTP Method, Request URL and Payload appear only when the entry has them. A PUBLISH entry shows JOB as its HTTP Method and internal://assistant-publish-pipeline-worker as its Request URL, because a publish runs as a background job, and it has no Payload: Published Changes takes its place. An ACTIVATE_VERSION entry has no Payload either. Sensitive fields such as passwords, API keys, and tokens are masked in stored payloads.

---

​

Filtering

Use the controls at the top of the log table to narrow results: The search box works within the Action and time range you have chosen. Changing the Action, the time range or Use UTC reloads the list and clears the search box, so set those first, then search.

---

​

Data Retention & Security

• Sensitive fields in event payloads, such as passwords, API keys, tokens, and client secrets, are masked before storage. Only a few characters at the start and end of a value may remain visible.
• Audit log entries are kept for 90 days and then removed automatically.
• Audit Logs aren’t limited to a particular role. Anyone with access to your account in Studio can open them, and they show entries for your own account only.