Skip to main content
Performance records are read-only QA data the system writes after an agent handles a call: pipeline latencies, token consumption, an automated quality assessment, and the full transcript including the agent’s tool calls. This is the same data the Dashboard shows under Performance Analysis. These records are separate from Calls. Calls are the customer-facing contact history (who called, what they wanted, the summary staff works with). Performance records are the technical and qualitative analysis of the same conversation — useful for monitoring agent quality, debugging slow responses, or feeding a QA dashboard.

Access

Permission: performance:read Issue an API key with this permission scoped to a single organization when a partner or internal tool needs read access to that organization’s QA data — that is narrower than granting Dashboard access, which would expose far more. With Dashboard JWT authentication the endpoints are additionally restricted to the super_admin, dev_admin, and dev_employee roles, mirroring the Dashboard’s own guard on the Performance Analysis page. client_admin and client_employee receive 403 FORBIDDEN.

List vs detail view

The transcript is detail-only on purpose: it is by far the largest field, and a list request would multiply it by the page size. Internal debug logs are never returned by the API.

Data model

Redflags. Seven fields carry an automated assessment of a specific failure pattern: assistant_misunderstood_multiple_times, repeated_same_sentence, abrupt_end_without_goodbye, connection_issue_repeated, assistant_policy_violation, technical_error, early_hangup_by_caller. Each is an object, not a boolean — check detected, do not test the field for truthiness: final_result: Detail-only field:

Endpoints

List performance records

Permission: performance:read | Pagination: yes (ordered by created_at descending) Filters:

Get performance record details

Permission: performance:read Returns one record including the full transcript.

Transcript format

The transcript is an array of objects — not a JSON string, and not the simple {role, text} array used by Calls. Do not reuse the parsing example from there. All entries live in one list sorted chronologically by time_sec (seconds since call start). Three kinds of entry are distinguished by role: Speech turn — role is user or assistant, the text is in text:
Tool call — the agent invoking a tool. arguments is a JSON string, not an object:
Tool result — the tool’s answer. The payload is in content, not in text:
Match a result to its invocation via tool_call_id. Parse accordingly:
transcript is null for calls recorded before transcript capture was enabled.

Personal data

Transcripts are partially redacted before they are stored: phone numbers, e-mail addresses, IBANs, and digit runs of seven or more are removed. Names and addresses remain in clear text. Treat the data accordingly, and scope keys to the organization that actually owns the calls.

Common patterns

Watch response latency over time

Find calls with a detected failure pattern

Export a date range with transcripts

The list view omits transcripts, so fetch the detail per record: