Action Logs
Every backend action that fires from a tool — email sent, webhook called, file delivered — is recorded here as a log entry. Use this page to confirm side-effects actually ran, look up a specific complaint by tracking ID, debug failed deliveries, and audit what the AI did on the user’s behalf.
The Action Logs page is reachable two ways: from the project sidebar (Action Logs — shows every tool’s actions in one list with a tool filter dropdown), or from a specific tool’s edit page (Delivery History — same UI scoped to that tool). Both pages share the same filters, table, and detail drawer.
How Rows Group
One user-facing event (a complaint, a reservation, a feedback submission) typically fires multiple backend actions — say, an email to the CX team plus a webhook to the CRM. Even though the database records each action as its own row, the list view groups them under a shared tracking ID so you see one row per invocation, not one per action.
The Actions column shows small icons indicating which action types ran — green when at least one of that type succeeded, red when all of that type failed. Click the row to open the detail drawer; if the invocation had multiple actions, the drawer renders them as tabs (Email / Webhook), each with its own forensic data.
This means a single complaint that emails three CX inboxes and posts to the CRM shows as one row with 2/3 ✓ deliveries (two emails accepted, one bounced) and a webhook icon — instead of as four separate rows that all carry the same tracking ID.
Filters
The filter bar above the table accepts:
| Filter | What it does |
|---|---|
| Tracking ID | Exact match on the tool’s tracking ID (e.g. SHK-8984690258). Backed by a B-tree index — sub-millisecond lookup, the primary CX use case (“the customer says they sent us SHK-X, find it”). |
| Tool (project-level page only) | Narrow to a single tool. Useful when you want every email/webhook for the complaints tool but not for, say, the bookings tool. |
| Status | success (everything fired ok), partial_success (mixed — at least one action succeeded and at least one didn’t), failed (every action of the invocation failed), skipped (a conditional rule blocked firing — see Conditional Actions). |
| From / To | ISO date range on executedAt. The “To” filter is treated as inclusive end-of-day so a single-day range works as expected. |
| Recipient | Narrows to invocations whose email actions targeted this address. Use this when a CX teammate says “I never got the email about complaint X” — filter by their address and status=failed to find bounce/skip cases. |
| Search | Free-text ILIKE match against subject + body (HTML and text). Helpful when the tracking ID isn’t known but a customer quoted a phrase from the email. |
Type freely; nothing fires until you press Search or hit Enter. Reset clears every filter and returns to the most recent invocations.
Pagination
The list shows 50 invocations per page with prev/next buttons and a Showing X–Y of Z counter at the top. Pagination operates at the action-row level (the API returns up to 50 rows per call); a single tracking ID’s actions are nearly always all on the same page, but if a high-fanout invocation happens to straddle a page boundary you may see the same group split — adjust the date range to narrow further when this matters.
Detail Drawer
Clicking a row opens a slide-in drawer with everything the system captured for that invocation. The top of the drawer shows shared metadata that’s identical for every action in the group — tool name, executed timestamp, expiration, tracking ID, end-user info, conversation link.
If the invocation had a single action, the action’s content (body, deliveries, request/response) renders directly. If it had multiple actions, they render as tabs so you can flip between Email and Webhook details without losing the shared header above. Each tab carries the per-action resolvedConfig, decisions, and parameters JSON viewers — they’re per-action snapshots, not shared.
Email Tab
- Subject — the resolved subject line (after
{{...}}token substitution). - Preview — opens the full HTML body in a sandboxed dialog. The iframe runs with
sandbox=""(no scripts, no forms, no top-level navigation) so malicious HTML can’t escape. - Delivery details — one row per recipient with target email, the routing condition that selected this address (when present), the provider’s message ID, error message on failure, and sent-at timestamp. Color-coded provider status — green for
accepted/delivered/sent/queued, red forfailed/bounced/rejected/dropped, amber for anything else.
Webhook Tab
- Sent request — the resolved URL, method, headers (with sensitive values like
AuthorizationandX-API-Keymasked), and the JSON or form-data summary that was actually sent. Captured from the runtime, not reconstructed from config — what you see here is what the receiver saw. - Receiver response — HTTP status code + status text, response headers, and parsed response body (truncated at 2KB if larger). Use this to confirm the receiver acknowledged the request and to read its error response on failure.
Both sections are collapsible JSON viewers with a copy-to-clipboard button.
Conversation Link
The drawer’s Open conversation link deep-links into the Conversations page with the matching session pre-selected — useful for reading the full chat that produced this invocation.
What Each Log Captures
Beyond the visible columns, each log row stores enough forensic data to answer questions weeks after the fact:
trackingId— the per-invocation reference number. Indexed for fast lookup.conversationId,sessionId,endUserId— tracing back into the chat platform.endUserContext— snapshot of the SDK-provideduserContextat the moment the action fired (only the keys the action’s allow-list opted into).subject,bodyHtml,bodyText— for email actions, the rendered message that went to the recipient.requestPayload,responsePayload— for webhook actions, the full HTTP request/response (sensitive headers masked, body truncated at 2KB).resolvedConfig— the action’s config after template substitution (e.g.subjectPrefix: "[Complaint] TRK-..."rather than"[Complaint] {{tool.trackingId}}").decisions— when conditional firing was used, the AI’s decision payload — which targets matched, the per-action fire/skip decision, and the AI’s reasoning.
Sensitive headers (Authorization, X-API-Key, X-Auth-Token, Cookie) are redacted at capture time — the DB row stores Bearer ab12***xx not the full token. The auto-set X-Qafka-Signature is also masked.
Why You’ll Open This Page
- Verifying delivery — a customer says they didn’t get the booking email — was it sent and bounced, or never sent? The log answers in one click.
- Tracking lookup — a customer references
SHK-8984690258; paste it into the Tracking ID filter to land directly on that invocation’s row. - Webhook debugging — your CRM webhook returned 500; the Sent Request + Receiver Response panels show the exact payload and response so you can reproduce locally.
- Compliance audit — someone asks “did our system send X person’s data anywhere?” — the log is the source of truth, including which
userContextkeys were forwarded and which recipients each email action reached. - Conditional routing audit — when a tool uses conditional actions or multi-target email routing, the
decisionsJSON viewer in the detail drawer shows the AI’s choice and reasoning.
Retention
Action logs auto-expire on a per-project window — default 30 days. A daily cron sweeps expired rows (and their per-recipient delivery rows) at 03:30 server time, plus backfills expiresAt for rows that were written before the field existed. Expired data is hard-deleted, not soft-deleted; export or archive externally if you need longer retention. The window is stored on the project record (actionLogRetentionDays) and can be lengthened or shortened by editing that column directly — no admin UI for it yet, ask if you need a different value.