Skip to main content
All Public API v1 list endpoints use cursor pagination. There is no page or offset parameter.

Parameters

Response shape

Ticket list responses do not include a total count. Use count on a saved view from GET /views when you need “how many tickets match this filter?”

Walkthrough — paginate tickets

Page 1:
Page 2 (use next_cursor from page 1):
URL-encode the cursor value when it contains | or other special characters. Stop when has_more is false or next_cursor is absent.

Paginating views and messages

The same pattern applies to:
  • GET /public/v1/views — default limit=50
  • GET /public/v1/tickets/:ticketNumber/messages — default limit=30, use order=asc for chronological threads

Anti-pattern — offset polling loops

Do not simulate pages with incrementing offsets or re-fetch page 1 in a tight loop:
Instead:
  1. Store next_cursor from each response.
  2. Request the next page only when has_more is true.
  3. Back off on rate limits (429).

Cursor stability

Cursors are opaque and tied to the sort order (created_at desc for tickets). Do not parse or construct cursors manually — always use the value returned by the API. If a cursor expires or becomes invalid, start a fresh list request without cursor.