Skip to main content
In Public API v1 ist view_id der einzige Weg, Ticket-Listen zu filtern. Status, Kanal, Priorität, Zuständigkeit, Tags und Datumsbereiche legst du in einer gespeicherten Posteingang-Ansicht an und führst sie per API aus.

Standard-Workflow

1

Ansichten auflisten

GET /public/v1/views — liefert id, name, count und filters pro Ansicht.
2

Ansicht wählen

Finde die Ansicht zu deinem Use Case (z. B. „Offen — letzte 7 Tage“ oder „Retouren“).
3

Tickets listen

GET /public/v1/tickets?view_id=<uuid> — Tickets gemäß Ansichtsfilter.
Beispiel:

Felder in der View-Antwort

Ungefilterte Liste

Ohne view_id alle Organisations-Tickets (mit Pagination):
Bei großen Workspaces sparsam nutzen — gespeicherte Ansichten begrenzen die Ergebnismenge.

Sortierung

Ticket-Listen sind sortiert nach created_at absteigend, dann Ticket-id absteigend. Das unterscheidet sich vom Posteingang-UI-Default (letzte Aktivität). Beim Vergleich mit der UI berücksichtigen.

In v1 nicht unterstützt

Unbekannte Query-Parameter → 400 VALIDATION_ERROR.

Ansichtszugriff

  • Agent-verknüpfte Schlüssel — nur sichtbare Posteingang-Ansichten.
  • Service-Schlüssel (ohne Agent) — alle Organisations-Ansichten.
Unzugängliche view_id404 VIEW_NOT_FOUND (nicht 403), auch bei Cross-Org-IDs oder für den Agenten verborgenen Ansichten.

Optionale Erweiterung

include=ticket_fields bei GET /tickets oder GET /tickets/:ticketNumber für benutzerdefinierte Ticketfelder.

Verwandt