Skip to main content
When you request a list of items from Sorsa API, the results are returned in pages. To retrieve the full dataset, you iterate through pages using cursors until no more data is available.

How cursor-based pagination works

Sorsa uses cursor-based pagination instead of traditional page numbers. This approach is more reliable for social media data, where new content is constantly being added and offset-based pagination would skip or duplicate results. The flow is the same for every paginated endpoint:
  1. Send your initial request without a cursor.
  2. The response includes your data and a next_cursor field.
  3. Pass the next_cursor value in your next request to fetch the next page.
  4. When next_cursor is null or absent from the response, you have reached the end.
Not every endpoint uses pagination. Single-object endpoints like /info, /tweet-info, /score, and /about return one result and have no cursor. Pagination only applies to endpoints that return lists of users or tweets.

Response structure

Paginated responses always follow one of these two patterns:
The data is always in the users or tweets array. The next_cursor field is a string when more pages exist, and null or absent when you have reached the end. For full details on response wrappers and object schemas, see Response Format.

How cursors are passed

The cursor field is always called next_cursor. The only difference between endpoints is where you put it: GET endpoints take it as a query parameter, POST endpoints take it in the JSON body. GET endpoints (like /followers, /follows, /list-tweets) take next_cursor as a query parameter:
POST endpoints (like /search-tweets, /user-tweets, /comments) take next_cursor in the JSON body:

Page sizes are not fixed

Due to the nature of X platform data, the number of items returned per page can vary. An endpoint that returns up to 20 items per page might return 18, 12, or even 5 on a given page, even when more data exists on the next page. Never use the item count to decide whether you have reached the end. A page with fewer items than expected does not mean there is no more data. Always check the next_cursor field. If it exists and is not null, there are more pages to fetch.

Full pagination examples

Python: paginating through followers (GET endpoint)
Python: paginating through search results (POST endpoint)
JavaScript: paginating through followers (GET endpoint)
JavaScript: paginating through search results (POST endpoint)

Pagination with error handling

In production, combine pagination with retry logic so that a single failed page does not break your entire data collection run. For the full error handling reference, see Error Codes.

Next steps

  • Rate Limits - Understand the 20 req/s limit when paginating through large datasets
  • Error Codes - Handle 429 and other errors during pagination loops
  • Response Format - Full reference for User and Tweet object schemas