Skip to main content

​
Overview

Several Chief API list endpoints use cursor-based pagination so you can walk large datasets without offset drift. Paginated responses include: Use resource ids as cursors. The cursor id is excluded from the next page (the page starts strictly after or before that id).

​
Supported endpoints

​
Parameters

All cursor-paginated endpoints accept:
​
integer
default:"25"
Maximum items per page. Minimum 1, maximum 100.
​
string
Resource id from the previous response’s last_id. Returns items strictly after this id. Omit on the first request. Mutually exclusive with before_id.
​
string
Resource id to paginate backward from. Returns items strictly before this id. Mutually exclusive with after_id.

​
Response format

Chats are returned newest first. Assets follow the same list envelope.

​
Forward pagination

Pass last_id from the current page as after_id on the next request when has_more is true:

​
Backward pagination

Pass first_id from the current page as before_id to walk toward older items:

​
Best practices

  • Check has_more before requesting another page.
  • Choose a limit that fits your use case (smaller for UI lists, larger for batch exports).
  • Do not send after_id and before_id in the same request.

​
FAQ

No. The page starts strictly after after_id, or strictly before before_id. The cursor id is excluded.
limit accepts 1 to 100 and defaults to 25. A value outside that range returns HTTP 400.
They are mutually exclusive. Sending both returns HTTP 400.
GET /v1/labels returns the full list in v1 rather than paging, so there is never another page to fetch.
Newest first. Assets use the same list envelope.
  • Introduction
  • Errors
  • API reference → Chats — GET /v1/chats
  • API reference → Assets — GET /v1/assets