tickets:read. Siehe Authentifizierung.
Kern-Tool-Set
Die meisten Agent-Integrationen exponieren vier Tools:
Schemas: Scalar.
Use Case 1 — „Zeig offene Tickets der letzten 7 Tage“
Gespeicherte Ansichten kodieren Filter. Der Agent listet Views, wählt eine passende (offen + recent), listet Tickets. Schritte:GET /public/v1/views—nameundfiltersnach passender Ansicht durchsuchen.GET /public/v1/tickets?view_id=<uuid>&limit=40— Ticket-Zusammenfassungen ans LLM oder den Nutzer.
Use Case 2 — „Fasse Ticket #1234 zusammen“
Schritte:GET /public/v1/tickets/1234/messages?order=asc&limit=100— chronologischer Thread.messages[].textkonkatenieren (max. 10.000 Zeichen pro Nachricht) und ans eigene LLM-Summarization geben.
GET /public/v1/tickets/1234 für Betreff, Status, Kontakt, Tags.
Interne Notizen, Entwürfe und System-Events sind in Message-Responses ausgeschlossen.
Use Case 3 — „Wie viele offene Tickets in meiner Retouren-Ansicht?“
Nicht alle Tickets paginieren zum Zählen. Nutzecount der Ansicht:
Schritte:
GET /public/v1/views— Ansicht mitname„Retouren“ (o. ä.) finden.countaus dem View-Objekt lesen.
count kann einige Sekunden hinter dem Posteingang liegen (Read-Replica).
OpenAI Tool-Definitionen (Beispiel)
Claude Tool-Definitionen (Beispiel)
tool_result sollte den API-Body unverändert durchreichen (success, data, pagination).
Tipps für Agent-Design
- View-Namen in Tool 1 auflösen — Modell wählt
view_idauslist_inbox_views, statt UUIDs zu hardcoden. - Ticketnummern nutzerseitig — URLs verwenden
#1234/ticket_number, nicht UUIDs. - Lange Threads paginieren — bei
has_more: truepagination.next_cursorfolgen. - 404 sinnvoll behandeln —
VIEW_NOT_FOUNDoft fehlende Agent-Sichtbarkeit; Service-Schlüssel oder andere Ansicht vorschlagen. - Rate Limits beachten — View-Listen cachen; nicht jeden Turn neu laden.