API changes: June 25, 2026

← Changelog · June 2026

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, 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, GET /v1/files 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 (list), GET /v1/note/collections/:id (one base), GET /v1/note/collections/:collectionId/documents (tree), GET /v1/note/documents/:id (document with Markdown), GET /v1/note/documents/search (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, PATCH /v1/note/collections/:id, POST /v1/note/documents, PATCH /v1/note/documents/:id) returned 400 with a Bitrix24 validation error, and attachment upload (POST /v1/note/documents/:documentId/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 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.