# Storages

Access to Bitrix24 Drive storages: employees' personal drives, workgroup drives, and the account's shared drive. This section is read-only: storages are created and deleted on the Bitrix24 Drive side; the API exposes listing, search, fetch by ID, and the field schema.

Bitrix24 API: `disk.storage.*`
Scope: `disk`

## Operations

- [List storages](./storages/list.md) — `GET /v1/storages`
- [Get a storage](./storages/get.md) — `GET /v1/storages/:id`
- [Search storages](./storages/search.md) — `POST /v1/storages/search`
- [Storage fields](./storages/fields.md) — `GET /v1/storages/fields`

## Key fields

| Field | Description |
|------|---------|
| `id` | Storage identifier |
| `name` | Storage name |
| `entityType` | Owner type: `user`, `group`, `common` |
| `entityId` | Owner identifier. A string — non-numeric for the shared drive, for example `shared_files_s1` |
| `rootFolderId` | Identifier of the storage root folder |

Full field list — [`GET /v1/storages/fields`](./storages/fields.md).

## What you need to know before you start

1. **This section is read-only.** Storages are created and deleted on the Bitrix24 Drive side: a personal drive exists for every employee, a workgroup drive is created together with the workgroup, and there is one shared drive per Bitrix24 account. There are no create, update, or delete operations through the API — listing, search, fetch by ID, and the field schema are available.
2. **Owner type — the `entityType` field.** Values: `user` — an employee's personal drive, `group` — a workgroup drive, `common` — the account's shared drive. The `entityId` field points to the owner of that type.
3. **`entityId` is a string, not a number.** For personal and workgroup drives it is a numeric identifier given as a string; for the shared drive the value is non-numeric, for example `shared_files_s1`. Do not cast it to a number.
4. **`rootFolderId` is the storage root folder.** The rest of the Drive content — folders and files — is reached from it. Field names in the response come back in camelCase. The `code` field comes back as `null` on the Bitrix24 accounts we checked.

## Typical scenario

1. List storages: [`GET /v1/storages`](./storages/list.md). Narrow by owner type — `filter[entityType]=group`.
2. Open a specific storage by ID: [`GET /v1/storages/:id`](./storages/get.md).
3. Take `rootFolderId` and fetch the content: [`GET /v1/folders?parentId={rootFolderId}`](/docs/entities/folders) for folders, then [`GET /v1/files?folderId={folderId}`](/docs/entities/files) for files in a folder.

## Limits

| Limit | Value |
|-------|----------|
| Maximum records per response | 5000 (`limit ≤ 5000`) |
| Auto-pagination | enabled when `limit > 50` |
| Full retrieval | result sets larger than 5000 records are read page by page with `offset` |
| Sorting | not supported — `order` / `sort` are rejected with `400 INVALID_SORT_FIELD` |
| Filtering | by exact field-value match |
| Batch requests | up to 50 read operations in [`POST /v1/batch`](/docs/batch) |
| Rate limit | shared across the Vibecode API — see [Limits and optimization](/docs/optimization) |

## See also

- [Entity reference](/docs/entities-index)
- [Filtering syntax](/docs/filtering)
- [Batch](/docs/batch) — combine multiple requests
- [Folders](/docs/entities/folders) — storage content
- [Files](/docs/entities/files) — files on Drive