---
title: "What is now true of the objects a client names, or of an area it names"
method: POST
path: "/disk.sync.state.check"
tags: ["disk"]
---

# What is now true of the objects a client names, or of an area it names

`POST /disk.sync.state.check`

Answers what the journal cannot: what a client still sees, after a position it can no
longer read from and after a boundary of visibility moved.

The method has two modes and the request chooses between them by what it carries. Name
`objectIds` to ask about the objects the memory of the client already holds. Name
`scopeRootId` to ask about an area - the root a change of access named. A request that
names both is refused, and so is one that names neither: guessing which was meant would
answer a question that was not asked.

Over a list the answer holds exactly one item per object, in the order the objects were
asked about. Over an area the answer is a page: ask for the next one with the
`nextCheckToken` of the previous, and stop when `hasMore` says the area is over. A page
that came back short is not the end of it - links inside an area collapse onto the object
they point at - and only `hasMore` answers that question.

An object the caller does not see is answered `visible: false` and carries no card. That
answer is the same for an object hidden from the caller and for an object that was never
there: the method never asks whether an object exists, so it cannot be used to find out.
For the same reason an area whose root the caller cannot see is answered with an empty
finished page rather than with a refusal - which is the ordinary case, not an edge one:
the first move of a reconciliation runs right after a revocation, when the root is already
invisible.

An area whose root is perfectly visible answers the same way when everything in it changed
too recently, and a client that reads an empty finished page as an empty area loses those
objects for good. A page is read against a boundary of state standing a little behind the
current instant, and what changed above that boundary enters no page of the walk. So an
empty finished first move does not mean an empty area: repeat the first move on the next
step of polling before treating the area as walked through. `safeWindowSeconds` is not that
boundary - it describes the journal and the initial fetch, while a walk over an area is read
against a narrower one of its own.

A visible object may arrive without a card. It was deleted between the verdict that named
it and the assembly that describes it; the client reads it back and waits for the journal
to say otherwise, rather than dropping an object it has just been told it can see.

The check answers about the state of right now. No depth of history is applied to it -
bounded by depth it would say "you do not see it" about a visible object that simply had
not changed for a long time - and objects in the trashcan are visible objects like any
other. The consequence is accepted: after a check the memory of a client may hold objects
older than the depth its session was given.

The check moves no cursor, reads no journal and neither needs a session nor touches one.
`checkToken` is its own kind of position with a boundary of state and a life of its own,
and an expired one is refused with CHECK_TOKEN_EXPIRED - a code of its own, so that a
client does not go and recreate a session the check never used. A token of another user,
of another application of the same user, of another kind or damaged in any way is refused
with CURSOR_INVALID.

## Request body

- object
  - `objectIds` integer[] — The mode over a list: the objects of the memory of the client, as its cards name them. An object named twice is answered about once. A list longer than the ceiling of a page is refused rather than trimmed, because a list has no continuation to hand the rest over by.
  - `scopeRootId` integer — The mode over an area: the object the area is rooted at, as a change of access named it. Sent beside a checkToken it has to name the same area the token was issued for.
  - `checkToken` string — Where the walk of the area stands. Absent from the first page - the portal opens the walk itself - and given back exactly as received on every page after it.
  - `limit` integer — How many objects of the area are asked for, 100 by default. Of the mode over an area alone. 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 - and a list of that many sections is bounded by the same number.
  - `sections` string[] — The sections of a card to fill on the visible objects of the answer. 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`

What is now true of the objects that were asked about.

- object
  - `result` object
    - `items` BitrixDiskCheckitemdto[] — One verdict per object. Over a list: the objects that were asked about, in the order they were asked about, once each. Over an area: the objects of the page, all of them visible.
      - `objectId` integer
      - `visible` boolean
      - `card` BitrixDiskObjectcarddto
        - `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 area goes on above this page. Absent from the answer over a list, which is the whole page there is.
    - `nextCheckToken` string — The position the next page of the area is asked for by, answered on the last page as well. Absent from the answer over a list.

## Other responses

- `400` — FEATURE_NOT_SUPPORTED, CHECK_TOKEN_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.state.check/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)