Home
...
FAQs
How do I paginate the results of the traces/query endpoint?

How do I paginate the results of the traces/query endpoint?

Use the sort and search_after fields in the request body to page through the results of the traces/query endpoint.

The traces/query endpoint has no pagination parameter in the URL. Pagination is handled by the fields of the search itself, in the request body.

Each response returns at most 10,000 records. To page through a larger result, use the search_after field.

IMPORTANT
The OpenSearch scroll and point in time strategies do not work on this endpoint:

Parameters passed in the URL, such as scroll, are ignored. The request returns 200 OK with a regular result, no scroll cursor, and no error warns you.

The pit field in the request body returns a 400 error, because the endpoint resolves the index automatically.

Simple pagination with from and size

For small volumes, use from and size in the request body. Their sum cannot exceed 10,000, which is the record limit per response.

See query best practices to choose the page size.

Continuous pagination with search_after

To page through larger results, use search_after. Instead of jumping to a position, you state where the previous page stopped.

Step 1

Build the first page with size and sort, as in the First page example below. The sort field is required and must end with a field that is unique per record, to act as a tiebreaker.

Step 2

In the response, find the last record in hits.hits and copy its sort array exactly as it came. The date appears as a number, and that is how it must be sent back.

Step 3

Repeat the request, without changing sort or query, adding the search_after field with the copied array, as in the Next page example below.

Step 4

Keep repeating step 3. The query ends when the response returns fewer records than the size you set.

First page:

Cursor in the response. The sort array of the last record in hits.hits is what you send back on the next page:

Next page:

IMPORTANT
Keep sort and query identical across all pages, and do not use from together with search_after. Differences between one page and the next may duplicate or skip records.

Closed time range

search_after does not freeze the search result. Since new calls keep being indexed while you page through the results, a search with no upper date bound changes content along the way.

To avoid that:

Set a range whose start and end are already in the past, as in the example above.
Sort in ascending order, so new records always land after the current position.

Fields to sort by

Field	Role in sorting
`sensedia.received_on`	Main sort, by date
`sensedia.request_id.keyword`	Tiebreaker, unique per record

sensedia.request_id is the record identifier, which is why it works as a tiebreaker. Being a text field, it can only be sorted in the version with the .keyword suffix. See fields with the .keyword suffix and the field mapping.

Page size

The size must fit within the API usage limits: 6 MB of response payload and a 29-second timeout.

Returning all fields of the record, the 6 MB limit is reached at around a few thousand records per page.
Use _source to return only the fields you need. That reduces the payload and allows larger pages.
By default, hits.total stops counting at 10,000 and returns "relation": "gte". Use track_total_hits when you need the exact total.

TIP
Paginated queries serve specific searches. If your use case is massive and constant data extraction, the recommended path is Data Streaming, which continuously sends the data to the destination you configure.

How happy are you with this page?

How can I search for data in the request/response header or body from traces?

Why do the exported data sometimes appear different depending on its destination?