# API changes: June 25, 2026

[← Changelog](/docs/changelog) · [June 2026](/docs/changelog/2026-06)

### FIX-0625-1: neutral provider, plan and region identifiers in the infrastructure API

**Before**

On the international (`.com`) surface, `GET /v1/infra/providers`, `GET /v1/infra/providers/:id/plans` and `GET /v1/infra/providers/:id/regions` returned provider, plan, disk-type and region identifiers in the underlying infrastructure's raw form rather than in the neutral brand namespace.

**After**

The same fields now use the neutral Bitrix Cloud namespace: provider `bitrix-cloud`, plans `bc-small`/`bc-medium`/`bc-large`/`bc-xlarge`, `diskType: "network-ssd"`, regions `bc-eu-central`/`bc-eu-west`/`bc-us-east`/`bc-us-west`/`bc-ap-southeast`. The `name` and `country` fields stay human-readable (for example "Frankfurt (EU Central)", `DE`). The same values are returned in the `provider`/`plan`/`region` fields of `GET /v1/infra/servers` and `GET /v1/infra/servers/:id`.

**Integrator impact**

The standard flow needs no changes: an identifier read from the catalog is still passed to `POST /v1/infra/servers` as-is. Server creation accepts both the new ids (`bitrix-cloud`/`bc-small`/`bc-eu-central`) and the ids from the previous catalog, so existing integrations keep working. Only update code that compares response identifiers against hard-coded strings from the previous provider, plan, or region catalog.

### FIX-0625-2: offset inside /v1/batch sub-calls now pages through results

**Before**

In [POST /v1/batch](/docs/batch), `list` and `search` sub-calls silently ignored `offset` in `params`: Bitrix24 received an unknown `offset` key instead of `start`, so every page returned the same first set of records. Three `contacts.search` sub-calls with `offset` 0, 50 and 100 all returned the identical first page.

**After**

`offset` in a `list`/`search` sub-call is mapped to Bitrix24's `start` (matching the single `POST /v1/{entity}/search` endpoint). The same three sub-calls now return three distinct, non-overlapping pages. Single-endpoint behavior is unchanged.

### FIX-0625-3: Files and folders: deletedBy on non-deleted objects is now null

**Before**

[GET /v1/files/:id](/docs/entities/files/get), [GET /v1/files](/docs/entities/files/list) and the folder endpoints returned `deletedBy: 0` for a non-deleted object, although the field is declared as `number | null` with "`null` — the object is not deleted". The sibling field `deletedAt` correctly returned `null`, so two fields with the same contract behaved differently, and a `deletedBy !== null` check wrongly treated every active object as deleted.

**After**

`deletedBy` is normalized to `null` for non-deleted objects (Bitrix24 stores zero in the `DELETED_BY` column to mean "no user"; user id 0 does not exist). For deleted objects the field still carries the id of the deleting user.

**Impact on integrators**

The behavior now matches the documented `number | null` contract. Clients that checked `deletedBy === null` / `deletedBy !== null` now get the correct result for active objects.

### NEW-0625-4: Knowledge Base 2.0 reads — list bases, documents, tree, search

Read access to Knowledge Base 2.0: list the knowledge bases you can access (cursor pagination), get a knowledge base and a document by id (the document includes its Markdown content), the document tree of a knowledge base, and full-text search across documents. Scope `note`.

**Affected endpoints:** [GET /v1/note/collections](/docs/note/collections) (list), [GET /v1/note/collections/:id](/docs/note/collections) (one base), [GET /v1/note/collections/:collectionId/documents](/docs/note/documents) (tree), [GET /v1/note/documents/:id](/docs/note/documents) (document with Markdown), [GET /v1/note/documents/search](/docs/note/documents) (search by `query`).

### FIX-0625-5: Knowledge Base 2.0 methods (create, update, file upload) now work

**Before**

Creating and updating knowledge bases and documents ([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)) returned `400` with a Bitrix24 validation error, and attachment upload ([POST /v1/note/documents/:documentId/files](/docs/note/files)) stored the file but did not return its id in `data.id`.

**After**

The methods work: create and update return `200`, and create responses for knowledge bases, documents, and files carry the id in `data.id`. Archive, delete, and file retrieval already worked.

### FIX-0625-6: /v1/me: storage supportedVisibilities are now uppercase

**Before**

[GET /v1/me](/docs/keys-auth) returned `supportedVisibilities: ["private","public"]` (lowercase) in the `storage` block, but the upload endpoints accept only `PRIVATE`/`PUBLIC` (uppercase). An agent copying the value from the manifest hit `STORAGE_INVALID_VISIBILITY`.

**After**

`supportedVisibilities` is returned as `["PRIVATE","PUBLIC"]` — exactly the values the `visibility` upload parameter accepts.

**Impact on integrators**

If a client took the `visibility` value from `/v1/me` and uppercased it itself, nothing changes. If it passed the value as-is, uploads now succeed without an error.