How to paginate room and thread messages in the Pivot REST API.
Room messages and thread messages use cursor-based pagination, but they differ in how data is partitioned. This guide explains how to page through each endpoint without missing history.
Endpoint:
GET /v2/rooms/{room_id}/messagesRoom messages are stored in time partitions (about 28-day windows). Each request returns messages from one partition at a time, ordered newest first.
shard_has_more is true, continue within the same partition using next_cursor_sent_at and next_cursor_message_id.shard_has_more is false, move to the next older partition by setting cursor_sent_at to next_partition_cursor.next_partition_cursor is older than the room’s created_at timestamp.next_partition_cursor is always returned. An empty messages array can
still be a valid response when the current partition has no data.
Start at the current partition:
GET /v2/rooms/ROOM_ID/messagesIf you know messages exist around a specific date, you can jump directly to that partition:
GET /v2/rooms/ROOM_ID/messages?cursor_sent_at=2025-09-30T23:59:59ZPaginate within a partition:
GET /v2/rooms/ROOM_ID/messages?cursor_sent_at=2025-09-30T23:59:59Z&cursor_message_id=MSG_IDEndpoint:
GET /v2/rooms/{room_id}/threads/{parent_id}/messagesThread messages are scoped to a single partition (the parent message), so there is no partition navigation. Messages are returned oldest first.
For nested threads, parent_id refers to the top-level parent message (the
one without a parent), not the immediate reply.
has_more is true, pass next_cursor_sent_at and next_cursor_message_id to fetch the next page.GET /v2/rooms/ROOM_ID/threads/PARENT_ID/messages?cursor_sent_at=2025-09-30T23:59:59Z&cursor_message_id=MSG_IDmessages with a valid next_partition_cursor usually means the partition is empty, not that the room has no messages.cursor_sent_at and cursor_message_id when paginating.Not Found, verify the integration has access to the room (try another room-level endpoint).Was this guide helpful?