Skip to main content
Kolaria uses page-based pagination on the list endpoints that can grow without bound. Each of them takes page and limit query parameters and returns a pagination object you can build paging controls from.

Paginated endpoints

Other list endpoints are not paginated. Brand identities, integrations, schedules, event triggers, chats, skills, GEO projects, prompts, sequences, competitors and briefs return the full list. GEO traffic endpoints (traffic/log, traffic/journeys, traffic/pages) and GET /v2/agent-chats accept a limit only and return the most recent items. Visibility and traffic reads are windowed by days or from/to instead.

Query Parameters

integer
default:"10"
Items per page. Range: 1 to 100. The default depends on the endpoint (see the table above).
integer
default:"1"
The page number to retrieve. Pages start at 1.
Out-of-range values are rejected rather than clamped: limit=500 or page=0 returns 400 with an error such as limit: Too big: expected number to be <=100. GET /v1/posts also accepts sort (asc or desc by creation date, default desc) and the comma-separated filters status, contentType and brandIdentityId. GET /v1/feedback accepts status, kind and projectId.

Pagination Response

Every paginated response includes a pagination object:
object
Metadata about the current page and navigation options.

Request Examples

Fetch the first page with the default limit (10):

Building Pagination Controls

Use the pagination object to build navigation controls:

Best Practices

  • Use a distinct cache key for each combination of page, limit, sort and filters.
  • Invalidate paginated list caches after post updates, deletes, and completed generation jobs.
  • For a fuller strategy, see Caching.
Performance: Use smaller page sizes (5 to 20 items), especially for mobile clients.
Empty states: Always handle an empty items array in your UI.
Navigation: Use nextPage and previousPage to enable or disable buttons. These values are null when movement is not possible.

Edge Cases

Requesting a page beyond totalPages is not an error. The API returns 200 with an empty items array, nextPage: null and previousPage set to the page before the one you asked for. Stop paging when nextPage is null rather than guessing page numbers.
Values outside the allowed range are rejected with 400 and an error message naming the parameter. Non-numeric values fail the same way. Nothing is silently clamped.
When there are no items, totalItems is 0, totalPages is 1, the items array is empty, and both nextPage and previousPage are null.
totalItems and totalPages reflect the filtered result set. On GET /v1/posts, omitting status returns only published posts; pass status=draft,published to count drafts too.
Last modified on September 29, 2026