Pagination

Run and job history are paged with an opaque cursor, newest first. Cursors stay correct while new runs arrive — a page never skips or repeats a run because something started in the meantime.

How it works

1. Request the first page. Optionally set pageSize (default 25, maximum 100).
2. The response has items and a nextCursor.
3. Pass nextCursor back as cursor to get the next (older) page.
4. When nextCursor is null, there are no more pages.

curl "$NEXQDATA_API/api/scraper-agents/$AGENT_ID/runs?pageSize=100" \
  -H "X-Api-Key: $NEXQDATA_API_KEY"

# then
curl "$NEXQDATA_API/api/scraper-agents/$AGENT_ID/runs?pageSize=100&cursor=$NEXT_CURSOR" \
  -H "X-Api-Key: $NEXQDATA_API_KEY"

{
  "success": true,
  "data": {
    "items": [ ],
    "nextCursor": "eyJ0IjoiMjAyNi0wOS0yM1QwMjowMDowNFoiLCJpIjoiM2ZhOCJ9"
  }
}

Treat the cursor as opaque — don't build or modify it.

Paged endpoints

Page-numbered lists

Other lists take a page number instead of a cursor. Pass page (from 1) and pageSize (default 25, maximum 100); the response has items and total, the number of matches across all pages.

A page number can shift while new items arrive — if a run starts between two requests, the next page repeats one item. When you need a stable walk through history, use the cursor-paged run and job lists.

Dataset queries page by page and pageSize in the request body. See Query.