# API changes: November 11, 2026 [← Changelog](/docs/changelog) · [November 2026](/docs/changelog/2026-11) ### FIX-1111-1: deleted server sources remain accessible to the owner after key removal **Before** Another personal key of the owner received `404 SERVER_NOT_FOUND` from `GET /v1/infra/servers/:id/sources` and `DELETE /v1/infra/servers/:id/sources/:versionId` after the server and its key were deleted. The versions remained in storage. **After** An active personal key of the retained owner without the Cowork scope can read, download, and delete versions of a deleted server through `/v1/infra/servers/:id/sources*`. `GET /v1/me/sources` shows the id and working endpoint pointers. Saving a new version on the deleted server and publishing with it still return `404 SERVER_NOT_FOUND`. ### BC-1111-2: updating a list row keeps the symbolic code and rejects changing it > Old format supported until: not provided **Before** [PATCH /v1/lists/:iblockId/elements/:elementId](/docs/lists/elements/update) cleared the row's symbolic code on every update: the `fields.CODE` value never reached Bitrix24. A call with `fields.CODE` different from the current code answered `200`, and the code was silently erased. A row outside sections, sent back exactly as `GET` returned it with `"IBLOCK_SECTION_ID": null`, was refused with `403 BITRIX_ACCESS_DENIED`. **After** `fields.CODE` with the row's current code keeps the code. This method cannot change the code: Bitrix24 finds the row by ID and code together, so with `fields.CODE` different from the current one the row is not updated, and the response is a `422 BITRIX_ERROR` error. `"IBLOCK_SECTION_ID": null` is accepted as a row outside sections. **What integrators should do** Pass the row's current code from [GET /v1/lists/:iblockId/elements/:elementId](/docs/lists/elements/get) in `fields.CODE`: a row from the `GET` response can be sent to the update as is. If the integration passed a new value to change the code, remove that: the method does not change the code, and such a call now returns an error. ### FIX-1111-3: updating a list section accepts a root section from the GET response **Before** [PATCH /v1/lists/:iblockId/sections/:sectionId](/docs/lists/sections/update) refused a section at the root of the list sent back exactly as [GET /v1/lists/:iblockId/sections/:sectionId](/docs/lists/sections/get) returned it: `"IBLOCK_SECTION_ID": null` in `fields` was refused with `403 BITRIX_ACCESS_DENIED`, and the section was not updated. **After** `"IBLOCK_SECTION_ID": null` is accepted as the root of the list, the same as `0`. The section is updated and stays at the root. **Impact on integrators** No changes are needed. If the integration replaced `null` with `0` before updating a section, that replacement can be removed. ### FIX-1111-4: chat creation time in Open Channel session history matches the dialog metadata **Before** [POST /v1/openlines/sessions/history](/docs/openlines/history) returned the chat creation time in `data.chats[].dateCreate` shifted by the offset of the key user's time zone relative to the Bitrix24 server. For the same chat it differed from `data.dateCreate` in [POST /v1/openlines/dialogs/lookup](/docs/openlines/dialog). **After** Both endpoints return the same creation time for one chat. **Impact on integrators** The `data.chats[].dateCreate` field may be `null` if the key user has no access to the dialog metadata, Bitrix24 returned an error or did not respond within the timeout, the request is temporarily skipped because of repeated timeouts on the Bitrix24 account, or Bitrix24 returned metadata without a creation date or an invalid response. If you compensated for the shift yourself, remove that correction. ### FIX-1111-5: flowId is accepted when creating and updating tasks **Before** `POST /v1/tasks`, `PATCH /v1/tasks/{id}`, `POST /v1/batch` and `POST /v1/tasks/batch` with `flowId` returned `400 READONLY_FIELD`, and `GET /v1/tasks/fields` marked the field as read-only. **After** The field is sent to Bitrix24 as `FLOW_ID`; an active flow sets the assignee, workgroup and deadline itself; to take a task out of a flow, send `0`. ### BC-1111-6: Batch updates preserve null semantics for CRM and tasks > Old format supported until: not provided **Before** In [POST /v1/{entity}/batch](/docs/batch), CRM entity updates omitted fields set to `null`. For example, a deal comment remained unchanged even though a single request cleared it. In [POST /v1/batch](/docs/batch), a task update with `null` could clear a field instead of preserving its value, and `null` inside a task multiple string field became the text `"null"`. **After** In entity batches, the change affects updates to `deals`, `contacts`, `companies`, `leads`, `quotes`, `invoices`, and `items`: `null` can clear a field or reset it to zero according to Bitrix24 processing. Global batches preserve task fields set to `null` and omit `null` array elements on task updates. Other operations retain their previous behavior. **What integrators should do** To preserve a field of any listed CRM entity in an entity batch, omit it from the update: `null` can now clear a comment or reset an amount to zero. For tasks, `null` preserves the value. To clear a task description or deadline, pass an empty string; to reset the time estimate, pass `0`. Do not send a task update containing only `null` fields: it can return Bitrix24 error code `100`. Handling of CRM array elements set to `null` in global batches is unchanged. For unverified field types and other operations, parity of `null` handling between the two batch routes has not been established. ### NEW-1111-7: Calls meeting follow-ups The Vibecode API adds `POST /v1/calls/sync-followups/list` and `GET /v1/calls/sync-followups/:followupId` with the `syncconnector` scope. Only meetings of the webhook owner or OAuth token user are available, including for administrators. The list uses a cursor; selecting any AI field caps a page at 20. The methods are rolling out: they require `syncconnector` 26.100.0 and `rest` 26.1300.0 or later. Until the update reaches your Bitrix24 account, the call returns `422 METHOD_NOT_YET_AVAILABLE` with the target version in `error.release` — a sign of the rollout, not an integration error. [Documentation](/docs/calls/sync-followup) ### NEW-1111-8: 409 CONNECT_KEY_STRATEGY_MISMATCH error when re-enabling or rotating a Connect key If a platform administrator changes the key type of a Connect app, a key of the previous type issued through that app can no longer be re-enabled through [PATCH /v1/keys/:id](/docs/management-keys/update) with `status: "ACTIVE"` or rotated through [POST /v1/keys/:id/rotate](/docs/management-keys/rotate). Such calls return `409` with code `CONNECT_KEY_STRATEGY_MISMATCH`. To get a key of the new type, sign in through the app again. Other keys are unaffected, and the successful response remains HTTP 200. ### FIX-1111-9: File uploads preserve an active write pause **Before** An upload attempt could release an active write pause while the balance was positive. **After** `POST /v1/storage/objects/upload` and `POST /v1/storage/objects/multipart/create` preserve an enforced pause and return `402 BILLING_INSUFFICIENT`, even with a positive balance. Topping up and the 24-hour expiry continue to resume writes.