---
title: "One page of the initial fetch"
method: POST
path: "/disk.sync.snapshot.list"
tags: ["disk"]
---

# One page of the initial fetch

`POST /disk.sync.snapshot.list`

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.

## Request body

- object
  - `snapshotToken` string, required — Where the fetch stands. Opaque: it comes from disk.sync.session.create and then from every page, and is given back exactly as it was received.
  - `limit` integer — How many objects of the page are asked for, 100 by default. A value above the ceiling is refused rather than trimmed. A page that asks for a heavy section is served at most 50 objects - a shorter page, not a refusal. Both ceilings are published by disk.sync.capabilities.get.
  - `sections` string[] — The sections of a card to fill. Everything this portal serves when the parameter is absent. A section the portal declares but does not fill is refused when asked for rather than answered empty, and so is a parameter the schema does not declare at all.

## Response `200`

One page of the initial fetch.

- object
  - `result` object
    - `items` BitrixDiskObjectcarddto[] — The objects of the page.
      - `type` string
      - `objectId` integer
      - `name` string
      - `extension` string
      - `mimeType` string
      - `size` integer
      - `versionId` integer
      - `versionNumber` integer
      - `createdAt` string, date-time
      - `updatedAt` string, date-time
      - `createdBy` BitrixDiskEntityrefdto
        - `id` integer
        - `name` string
      - `updatedBy` BitrixDiskEntityrefdto
        - `id` integer
        - `name` string
      - `storageOwner` BitrixDiskEntityrefdto
        - `id` integer
        - `name` string
      - `contentAvailable` boolean
      - `downloadId` string
      - `places` unknown[]
        - unknown
      - `placeExpected` boolean
    - `folders` BitrixDiskObjectcarddto[] — Every folder the page needs the client to know: the folders its objects hang under, as far up as the caller may read, and the links of the caller that the paths of the page pass through. Not counted into the size of the page.
      - `type` string
      - `objectId` integer
      - `name` string
      - `extension` string
      - `mimeType` string
      - `size` integer
      - `versionId` integer
      - `versionNumber` integer
      - `createdAt` string, date-time
      - `updatedAt` string, date-time
      - `createdBy` BitrixDiskEntityrefdto
        - `id` integer
        - `name` string
      - `updatedBy` BitrixDiskEntityrefdto
        - `id` integer
        - `name` string
      - `storageOwner` BitrixDiskEntityrefdto
        - `id` integer
        - `name` string
      - `contentAvailable` boolean
      - `downloadId` string
      - `places` unknown[]
        - unknown
      - `placeExpected` boolean
    - `hasMore` boolean — Whether the fetch goes on.
    - `nextSnapshotToken` string — The position the next page is asked for by. Answered on the last page as well.
    - `warnings` object[] — What this page could not deliver. Empty in the usual case.
      - `resourceType` string
      - `resourceId` integer
      - `reason` string

## Other responses

- `400` — FEATURE_NOT_SUPPORTED, SYNC_EXPIRED, CURSOR_INVALID, BITRIX_REST_V3_EXCEPTION_VALIDATION_REQUESTVALIDATIONEXCEPTION
- `403` — ACCESS_DENIED
- `429` — BITRIX_REST_V3_EXCEPTION_RATELIMITEXCEPTION

## Changes

- **2026-09-29** `f6be0a558c33` — 1 info
  - endpoint added

[Change history](https://skmtc.dev/bitrix24/apis/bitrix24-rest-v3-api/changes/disk.sync.snapshot.list/post.md)

---

[API](https://skmtc.dev/bitrix24/apis/bitrix24-rest-v3-api.md) · [All operations](https://skmtc.dev/bitrix24/apis/bitrix24-rest-v3-api/llms.txt) · [OpenAPI document](https://skmtc.dev/bitrix24/apis/bitrix24-rest-v3-api/revisions/f6be0a558c33?raw)