One page of the initial fetch

Hands over the personal copy of a client page by page, in the order the client needs it rather than in the order the portal stores it.

The page is read against the state the session fixed, so a page is repeatable: an object that changes while the fetch is running neither moves between pages nor falls out of it. Ask for the next page with the nextSnapshotToken of the previous one, and stop when hasMore says the fetch is over. A page that came back short is not the end of the fetch - rows are lost to the collapsing of links and to the confirmation of the interaction set, and only hasMore says whether anything is left.

folders is a section of its own and is not counted into limit. Folders join the fetch by kinship - as the readable folders above the objects of the page - and not by their own freshness: the date a folder changed says nothing about the activity inside it, and a folder untouched for years may well hold the files a client asked for. Folders are deduplicated inside a page; a folder met again on a later page is normal and costs the client nothing, because applying the card of a folder is idempotent.

Every folder a path of the page names has a card in folders. A folder of somebody else that the caller reaches through a link of their own enters the path as that link, under the link's own name, and the card of that link is answered beside the ancestors. The one identifier that may be answered without a card is parentFolderId of a place whose path does not reach it: the folder then lies above the boundary of access, and no name of it is published anywhere.

snapshotToken stops being accepted at the snapshotTokenExpiresAt of its session, and a fetch that did not finish by then is started again with a new session rather than stitched onto the old one. The same refusal answers a token of a session that has since been replaced - opening a session again annuls the fetch of the previous one.

warnings names what the page could not deliver: an object deleted between the fetch that named it and the assembly that describes it arrives as a warning rather than as a card. The identifier is part of it, because that is what lets a client read the object back instead of discovering the gap by comparing counts.