Pagination

List responses use an opaque cursor and a bounded limit. Treat the cursor as a continuation token, not a resource ID, timestamp or authorization grant. Preserve the original account, endpoint, filters and sort semantics while requesting the next page.

Read each page once

Use the returned next cursor until it is absent. Do not derive a cursor from the last visible ID. A list envelope is not just an array: the SDK preserves the original pagination fields, and CLI JSON modes retain the documented output shape. The generated reference specifies each list's limit and filter parameters.

Changing filters, account or endpoint requires a new first-page request. Current authorization still applies to every page; a previously valid cursor cannot keep a revoked key or expired console session alive. Deleted or newly created resources can change the available view while you traverse it, so do not treat a traversal as a transactional backup.

For events, use the retained event cursor and the event feed's own lifetime semantics. For a single asynchronous task, poll its operation directly rather than repeatedly listing all computers.

Response envelopes

Control lists, including classes, accept limit 1 through 200 (default 50), cursor, and return data, next_cursor and has_more. Data-plane lists use data without a cursor; file listing also carries path. Desktop windows is a bare array. Events uses after/wait and data plus next_cursor, without has_more. Do not feed one envelope into another paginator. The generated operation examples preserve these distinctions.

Dory is in development; these pages describe the planned service and may change. Questions: support@computeengines.com.