Pagination and result jobs
Choose the paging protocol used by your resource
List endpoints do not all use the same paging model. Follow the response from the specific route.
| Family | Paging |
|---|---|
| Projects, pipelines, runs, endpoint lists, bindings and query lists | limit and offset; shared helper defaults to 100 and accepts 1–500; returns pagination with limit, offset, count, hasMore |
| Members | Cursor-based member listing; follow its returned cursor |
| Query execution history and usage operations | Offset-based activity listing; follow the returned continuation |
| Endpoint records | Bounded record page and opaque cursor tied to the read/caller/snapshot |
| Published queries | Execution options.limit, offset, cursor or jobId |
| Integration corrections | Correction cursor |
For offset lists, request the next offset only when hasMore is true. Concurrent edits may shift a list; do not assume offset paging is an immutable snapshot.
Published query results
The first execution sends the query's actual input contract and an options object. A 202 response means result work is pending. Inspect its job metadata and continue using the execution endpoint with options.jobId when directed. Once a cursor is returned, use it for subsequent pages.
Do not combine cursor and jobId. Offset must be zero when using either. The cursor and result job belong to the caller and query; retain the same credential and respect expiry. Do not change input or release selection while following a result.
The job resource supports DELETE for an active query result job; it is not a generic pipeline job endpoint. The query guide explains execution and cancellation.