tickets:read. See Authentication.
Core tool set
Most agent integrations expose four tools:
Link to Scalar for full request/response schemas.
Use case 1 — “Show open tickets from the last 7 days”
Saved views encode filters. The agent discovers views, picks one that matches “open + recent”, then lists tickets. Steps:GET /public/v1/views— scannameandfiltersfor a view like “Open — last 7 days”.GET /public/v1/tickets?view_id=<uuid>&limit=40— return ticket summaries to the user or downstream LLM.
Use case 2 — “Summarize ticket #1234”
Steps:GET /public/v1/tickets/1234/messages?order=asc&limit=100— chronological thread.- Concatenate
messages[].text(respect the 10,000 character per-message cap) and pass to your LLM summarizer.
GET /public/v1/tickets/1234 first for subject, status, contact, and tags.
Internal notes, drafts, and system events are excluded from message responses.
Use case 3 — “How many open tickets in my Returns view?”
Do not paginate all tickets to count them. Use the view’scount field:
Steps:
GET /public/v1/views— find the view wherenamematches “Returns” (or similar).- Read
countfrom that view object.
count reflects the current filter snapshot and may lag the inbox by a few seconds (read replica).
OpenAI tool definitions (example)
Claude tool definitions (example)
tool_result JSON — pass the API response body through unchanged so the model sees success, data, and pagination.
Agent design tips
- Resolve view names in tool 1 — let the model pick
view_idfromlist_inbox_viewsoutput instead of hard-coding UUIDs. - Use ticket numbers in user-facing paths — URLs use
#1234/ticket_number, not UUIDs. - Paginate messages for long threads — follow
pagination.next_cursorwhenhas_moreis true. - Handle 404 gracefully —
VIEW_NOT_FOUNDoften means the linked agent cannot see that view; suggest a service key or different view. - Respect rate limits — cache view lists; avoid re-fetching on every turn.