# Изменения API: 25 июня 2026

[← Журнал изменений](/docs/changelog) · [Июнь 2026](/docs/changelog/2026-06)

### FIX-0625-1: нейтральные идентификаторы провайдера, плана и региона в инфраструктурном API

**Было**

На международной (`.com`) поверхности `GET /v1/infra/providers`, `GET /v1/infra/providers/:id/plans` и `GET /v1/infra/providers/:id/regions` отдавали идентификаторы провайдера, планов, типа диска и регионов в сыром виде нижележащей инфраструктуры, а не в нейтральном пространстве имён бренда.

**Стало**

Те же поля приведены к нейтральному пространству имён бренда Bitrix Cloud, как в российском сегменте: провайдер `bitrix-cloud`, планы `bc-small`/`bc-medium`/`bc-large`/`bc-xlarge`, `diskType: "network-ssd"`, регионы `bc-eu-central`/`bc-eu-west`/`bc-us-east`/`bc-us-west`/`bc-ap-southeast`. Поля `name` и `country` остаются человекочитаемыми (например, «Frankfurt (EU Central)», `DE`). Те же значения возвращаются в полях `provider`/`plan`/`region` ответов `GET /v1/infra/servers` и `GET /v1/infra/servers/:id`.

**Влияние на интеграторов**

Стандартный сценарий не требует изменений: идентификатор, полученный из каталога, по-прежнему передаётся в `POST /v1/infra/servers` без правок. При создании сервера принимаются и новые идентификаторы (`bitrix-cloud`/`bc-small`/`bc-eu-central`), и идентификаторы из прежнего каталога, поэтому существующие интеграции продолжают работать. Поправьте только код, который сверяет идентификаторы ответа с захардкоженными строками из прежнего каталога провайдера, планов или регионов.

### FIX-0625-2: offset внутри подвызовов /v1/batch теперь листает страницы

**Было**

В [POST /v1/batch](/docs/batch) подвызовы `list` и `search` молча игнорировали `offset` в `params`: B24 получал неизвестный ключ `offset` вместо `start`, поэтому каждая страница возвращала один и тот же первый набор записей. Три подвызова `contacts.search` с `offset` 0, 50 и 100 отдавали идентичную первую страницу.

**Стало**

`offset` в подвызове `list`/`search` переводится в `start` Bitrix24 (как в одиночном `POST /v1/{entity}/search`). Те же три подвызова теперь возвращают три разные непересекающиеся страницы. Поведение одиночного эндпоинта не изменилось.

### FIX-0625-3: Файлы и папки: deletedBy у не удалённых объектов теперь null

**Было**

[GET /v1/files/:id](/docs/entities/files/get), [GET /v1/files](/docs/entities/files/list) и эндпоинты папок возвращали `deletedBy: 0` у не удалённого объекта, хотя поле объявлено как `number | null` с «`null` — объект не удалён». Поле-сосед `deletedAt` при этом корректно отдавало `null`, так что два поля с одинаковым контрактом вели себя по-разному, и проверка `deletedBy !== null` ошибочно считала каждый активный объект удалённым.

**Стало**

`deletedBy` нормализуется в `null` для не удалённых объектов (Битрикс24 хранит в колонке `DELETED_BY` ноль как «нет пользователя»; пользователя с id 0 не существует). У удалённых объектов поле по-прежнему содержит id пользователя, выполнившего удаление.

**Влияние на интеграторов**

Поведение приведено к задокументированному контракту `number | null`. Клиенты, проверявшие `deletedBy === null` / `deletedBy !== null`, теперь получают корректный результат для активных объектов.

### NEW-0625-4: чтение Базы знаний 2.0 — список баз, документы, дерево, поиск

Read-доступ к Базе знаний 2.0: список доступных баз знаний (курсорная пагинация), получение базы знаний и документа по идентификатору (документ — с Markdown-содержимым), дерево документов базы знаний и полнотекстовый поиск по документам. Скоуп `note`.

**Затронутые эндпоинты:** [GET /v1/note/collections](/docs/note/collections) (список), [GET /v1/note/collections/:id](/docs/note/collections) (одна база), [GET /v1/note/collections/:collectionId/documents](/docs/note/documents) (дерево), [GET /v1/note/documents/:id](/docs/note/documents) (документ с Markdown), [GET /v1/note/documents/search](/docs/note/documents) (поиск по `query`).

### FIX-0625-5: методы Базы знаний 2.0 (создание, изменение, загрузка файлов) теперь работают

**Было**

Создание и изменение баз знаний и документов ([POST /v1/note/collections](/docs/note/collections), [PATCH /v1/note/collections/:id](/docs/note/collections), [POST /v1/note/documents](/docs/note/documents), [PATCH /v1/note/documents/:id](/docs/note/documents)) возвращали `400` с ошибкой валидации Битрикс24, а загрузка вложения ([POST /v1/note/documents/:documentId/files](/docs/note/files)) сохраняла файл, но не возвращала его идентификатор в `data.id`.

**Стало**

Методы работают: создание и изменение возвращают `200`, а ответы создания баз знаний, документов и файлов содержат идентификатор в `data.id`. Архивирование, удаление и получение файла работали и раньше.

### FIX-0625-6: /v1/me: supportedVisibilities хранилища теперь в верхнем регистре

**Было**

[GET /v1/me](/docs/keys-auth) в блоке `storage` отдавал `supportedVisibilities: ["private","public"]` в нижнем регистре, а эндпоинты загрузки принимают только `PRIVATE`/`PUBLIC` (верхний регистр). Агент, скопировавший значение из манифеста, получал `STORAGE_INVALID_VISIBILITY`.

**Стало**

`supportedVisibilities` отдаётся как `["PRIVATE","PUBLIC"]` — ровно те значения, которые принимает параметр `visibility` при загрузке.

**Влияние на интеграторов**

Если клиент брал значение `visibility` из `/v1/me` и приводил его к верхнему регистру сам — ничего не меняется. Если передавал как есть — теперь загрузка проходит без ошибки.