[{"data":1,"prerenderedAt":7},["ShallowReactive",2],{"docs-changelog\u002F2026-06-25":3,"docs-tabs-changelog\u002F2026-06-25":6},{"content":4,"lastmod":5},"# API changes: June 25, 2026\n\n[← Changelog](\u002Fdocs\u002Fchangelog) · [June 2026](\u002Fdocs\u002Fchangelog\u002F2026-06)\n\n### FIX-0625-1: neutral provider, plan and region identifiers in the infrastructure API\n\n**Before**\n\nOn the international (`.com`) surface, `GET \u002Fv1\u002Finfra\u002Fproviders`, `GET \u002Fv1\u002Finfra\u002Fproviders\u002F:id\u002Fplans` and `GET \u002Fv1\u002Finfra\u002Fproviders\u002F:id\u002Fregions` returned provider, plan, disk-type and region identifiers in the underlying infrastructure's raw form rather than in the neutral brand namespace.\n\n**After**\n\nThe same fields now use the neutral Bitrix Cloud namespace: provider `bitrix-cloud`, plans `bc-small`\u002F`bc-medium`\u002F`bc-large`\u002F`bc-xlarge`, `diskType: \"network-ssd\"`, regions `bc-eu-central`\u002F`bc-eu-west`\u002F`bc-us-east`\u002F`bc-us-west`\u002F`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`\u002F`plan`\u002F`region` fields of `GET \u002Fv1\u002Finfra\u002Fservers` and `GET \u002Fv1\u002Finfra\u002Fservers\u002F:id`.\n\n**Integrator impact**\n\nThe standard flow needs no changes: an identifier read from the catalog is still passed to `POST \u002Fv1\u002Finfra\u002Fservers` as-is. Server creation accepts both the new ids (`bitrix-cloud`\u002F`bc-small`\u002F`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.\n\n### FIX-0625-2: offset inside \u002Fv1\u002Fbatch sub-calls now pages through results\n\n**Before**\n\nIn [POST \u002Fv1\u002Fbatch](\u002Fdocs\u002Fbatch), `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.\n\n**After**\n\n`offset` in a `list`\u002F`search` sub-call is mapped to Bitrix24's `start` (matching the single `POST \u002Fv1\u002F{entity}\u002Fsearch` endpoint). The same three sub-calls now return three distinct, non-overlapping pages. Single-endpoint behavior is unchanged.\n\n### FIX-0625-3: Files and folders: deletedBy on non-deleted objects is now null\n\n**Before**\n\n[GET \u002Fv1\u002Ffiles\u002F:id](\u002Fdocs\u002Fentities\u002Ffiles\u002Fget), [GET \u002Fv1\u002Ffiles](\u002Fdocs\u002Fentities\u002Ffiles\u002Flist) 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.\n\n**After**\n\n`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.\n\n**Impact on integrators**\n\nThe behavior now matches the documented `number | null` contract. Clients that checked `deletedBy === null` \u002F `deletedBy !== null` now get the correct result for active objects.\n\n### NEW-0625-4: Knowledge Base 2.0 reads — list bases, documents, tree, search\n\nRead 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`.\n\n**Affected endpoints:** [GET \u002Fv1\u002Fnote\u002Fcollections](\u002Fdocs\u002Fnote\u002Fcollections) (list), [GET \u002Fv1\u002Fnote\u002Fcollections\u002F:id](\u002Fdocs\u002Fnote\u002Fcollections) (one base), [GET \u002Fv1\u002Fnote\u002Fcollections\u002F:collectionId\u002Fdocuments](\u002Fdocs\u002Fnote\u002Fdocuments) (tree), [GET \u002Fv1\u002Fnote\u002Fdocuments\u002F:id](\u002Fdocs\u002Fnote\u002Fdocuments) (document with Markdown), [GET \u002Fv1\u002Fnote\u002Fdocuments\u002Fsearch](\u002Fdocs\u002Fnote\u002Fdocuments) (search by `query`).\n\n### FIX-0625-5: Knowledge Base 2.0 methods (create, update, file upload) now work\n\n**Before**\n\nCreating and updating knowledge bases and documents ([POST \u002Fv1\u002Fnote\u002Fcollections](\u002Fdocs\u002Fnote\u002Fcollections), [PATCH \u002Fv1\u002Fnote\u002Fcollections\u002F:id](\u002Fdocs\u002Fnote\u002Fcollections), [POST \u002Fv1\u002Fnote\u002Fdocuments](\u002Fdocs\u002Fnote\u002Fdocuments), [PATCH \u002Fv1\u002Fnote\u002Fdocuments\u002F:id](\u002Fdocs\u002Fnote\u002Fdocuments)) returned `400` with a Bitrix24 validation error, and attachment upload ([POST \u002Fv1\u002Fnote\u002Fdocuments\u002F:documentId\u002Ffiles](\u002Fdocs\u002Fnote\u002Ffiles)) stored the file but did not return its id in `data.id`.\n\n**After**\n\nThe 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.\n\n### FIX-0625-6: \u002Fv1\u002Fme: storage supportedVisibilities are now uppercase\n\n**Before**\n\n[GET \u002Fv1\u002Fme](\u002Fdocs\u002Fkeys-auth) returned `supportedVisibilities: [\"private\",\"public\"]` (lowercase) in the `storage` block, but the upload endpoints accept only `PRIVATE`\u002F`PUBLIC` (uppercase). An agent copying the value from the manifest hit `STORAGE_INVALID_VISIBILITY`.\n\n**After**\n\n`supportedVisibilities` is returned as `[\"PRIVATE\",\"PUBLIC\"]` — exactly the values the `visibility` upload parameter accepts.\n\n**Impact on integrators**\n\nIf a client took the `visibility` value from `\u002Fv1\u002Fme` and uppercased it itself, nothing changes. If it passed the value as-is, uploads now succeed without an error.\n",null,{},1794739467458]