The Ticket Record Page and Its API: Every Section, and the Tool That Reads It

Every "View in Qvasa" button lands on the ticket record page: one ticket, every fact Qvasa holds about it, section by section. The same sections are readable through the User Access API as the single-ticket drill-in tools, one tool per section, so an AI agent or a script can answer "who worked on this ticket", "what did the customer say" or "which classifications fired" without a dashboard. This guide walks the page and names the tool behind each section.

Before You Start

Opening the page. Click View in Qvasa on any table row or inspect drill-in, or open /tickets/<qvasa ticket id>. Anyone who can drill into ticket details can open it; the conversation sections also need the conversational-data permission.
Reading through the API. A token needs can_read_all_endpoints and can_inspect_objects, and its user needs can drill into ticket details. The seven conversation tools additionally need the token scope can_access_conversational_data and the user permission to see conversational data. Both the token and the user must have it: a scope the user lacks is stripped at request time.
Integrations decide which sections exist. Talk, Sunshine Conversations, Zendesk Chat and Quiq sections appear only on accounts with those integrations, on the page and in the API catalog alike.

Step 1: Two Calls That Teach the Rest

Start an agent on two discovery calls. POST /user_access/api/single_ticket_drill_ins/concept_overview returns a static orientation document: the lookup rule, the scope split, the pagination shape, a five-step workflow and the four common pitfalls. POST /user_access/api/single_ticket_drill_ins/index returns the catalog of sub-tools available on this account, already filtered by integration, each with its method, path and parameters. Call index first on a new account; it is the only way to know which sections are reachable.

Step 2: Name the Ticket

Every sub-tool takes exactly one of two keys: qvasa_ticket_id (the integer in the page URL and in every ticket-set response) or zendesk_ticket_id (the Zendesk ticket number, treated as a string). Passing both returns 422 ticket_lookup_ambiguous; passing neither returns 422 ticket_lookup_missing. Lookups are scoped to the token's account, and a ticket from another account answers 404 exactly like a nonexistent one.

Step 3: Walk the Page, Section by Section

The page from top to bottom, with the tool that returns the same facts. Sections marked "page only" have no API tool yet.

Page section	API sub-tool	Scope	What it returns
Ticket Information (status, channel, opening and closing times, present wait, Zendesk link, tags)	`ticket_overview`	public	One object: the metadata plus a `counts` block for every list tool, so an agent can budget its pagination. Tags are their own list, `tags`, with the time each was set.
Ticket Status Timeline and Ticket Custom Statuses	`state_history`	public	The processed state timeline: every status and dynamic-field state in order, with durations and a total. Capped at 500 entries with a `truncated` flag.
AI Attributes and Full AI Ticket Summary	`contact_reasons`, `generative_reasons`, `qualitative_question_responses`; summaries on `ticket_conversation_overview`	public; the summary is conversational	Contact reasons as one flat object (initial, current, explanation, DSAT, product, agent intervention), the free-form AI reason codes, and each classifier's response with its question name and status.
Static Attributes	`static_attributes`, `static_boolean_values`	public	Zendesk's static fields (priority, type) with when each value was set, and the boolean ones (CSAT response) separately.
Zendesk Custom Field Values	`custom_field_values`	public	Text, dropdown and multiselect values in one object, no pagination.
Qvasa Custom Field Values	page only		Qvasa-side custom fields are not in the drill-in set yet.
Ticket Assignments	`assignment_history`	public	Every agent assignment with start, end and solved-at times, newest first by default.
Ticket Groups	`group_change_history`	public	Every group the ticket sat in, with start and end.
Talk Call History (and its work item timeline)	`phone_calls_zendesk_talk`, `phone_calls_ticket`, `agent_status_records`	public	Zendesk Talk's per-call records, Qvasa's per-ticket call records (type, duration, who answered), and the agent status trace while the call was worked, including ringing outcomes.
Messaging Work Item History	`agent_status_records`	public	The per-agent work item trace: offered, active, ended, with timestamps. The same tool serves Talk and messaging; the channel is on each row.
Channel History, Omnichannel Routing and Skills, Agent QA Grades	page only		Queue stays are readable through the queue events table widget (see the related guide); skills and QA grades have no drill-in tool yet.
Zendesk Ticket Comments	`zendesk_comments`	conversational	Public and private comments with actor type, agent attribution and text, oldest first by default.
Ticket Conversation (the unified thread)	`ticket_conversation_overview`, `ticket_conversation_messages`	conversational	The subject (derived from customer messages), the long and short AI summaries and message count; then the full thread with sender type and role, chronological by default.
AI Bot Conversation (Zendesk Chat)	`zendesk_chats`	conversational	Chat sessions with their nested events. Heavy: pages of 10, at most 50.
Sunshine Conversation Data and Bot Interactions	`sunshine_conversation_messages`, `sunshine_bot_interactions`	conversational	Messages (pages of 25, capped at 200) and bot interactions with bot name, counts, start, end and close reason.
Quiq Conversation, Agent Assignments, Ownership Timeline	`quiq_conversations`	conversational	Conversations with nested messages. Heavy: pages of 10.
Related Tickets, Side Conversations, SweetHawk Tasks and Subtickets	page only		Not in the drill-in set yet.
Incoming Ticket Events and Webhook Events Record	not exposed, by design		The API serves processed data only; for what happened when, use `state_history`.

Step 4: Page Through Long Sections

List tools paginate with a cursor: pass after_id from the previous page's next_cursor. Each response carries a pagination block (has_more, next_cursor, sort field and direction) and a next_step with the next page's URL already filled in.
Default page sizes: 20 for most lists, 25 for conversation messages, 10 for the heavy chat and Quiq lists; the maximum is 100.
Each list declares its natural order and the sort keys it accepts: newest first for event history (assignments, groups, tags, calls), oldest first for conversation reading (messages, comments, chats). Pass sort to flip it.
Single-object tools (overview, state history, custom field values, contact reasons, conversation overview) have no pagination.

For AI Agents: the Workflow

Read concept_overview once, then index on each account to learn what is reachable.
Pick the sub-tool that matches the question: who worked it, assignment history; what the customer said, conversation messages; which classifications fired, qualitative question responses; what happened when, state history.
Call it with exactly one ticket key; paginate while has_more is true.
For a multi-section question, fan out across sub-tools: each is one account-scoped, ticket-scoped query.
Expect 403 permission_denied, naming the missing scope, on a conversational tool without the conversational scope; and a sub-tool missing from index on an account without its integration.

FAQ

Which id do I use? Either the Qvasa id from the page URL or the Zendesk ticket number, never both.
Why does a section on the page have no tool? The drill-in set covers the processed ticket facts an agent asks about most; Qvasa custom fields, channel history, routing and skills, QA grades, related tickets, side conversations and SweetHawk items are page only today. Raw webhook events are not exposed on purpose.
Why is the subject only on the conversational overview? The subject is derived from customer messages, so it is conversational data and follows that permission.
Where are the queue stays? On the Omnichannel Queue Changed Events table widget, filtered to the ticket; the queue events guide covers every column.