Returns one page of tasks.
The optional status query parameter filters by lifecycle state.
Valid status values: pending, running, succeeded, failed, cancelled.
Anything else is a 400.
Response
Paging
Pass next_cursor back as cursor and repeat while has_more is true.
limit defaults to 100 and caps at 1000; anything outside 1..1000 is a 400.
A task carries its full attempt history, so a large page can be a large response body.
The cursor is opaque. Don’t construct, parse, or store it long-term - it encodes Schedy’s internal key layout, which is not part of the API contract.
A cursor is only valid for the same status filter that produced it; mixing them returns a 400.
Paging is keyset-based, not offset-based.
Tasks created or deleted between pages will not shift rows across a page boundary, and a cursor stays valid even if the task it points at is deleted mid-walk.
Tasks that reach a terminal state between pages move to a different status partition, so a walk of ?status=pending can miss one that just fired - page ?status=succeeded and ?status=failed for the outcome.
Example: page through everything