API changes: November 11, 2026

← Changelog · November 2026

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 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 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 refused a section at the root of the list sent back exactly as GET /v1/lists/:iblockId/sections/:sectionId 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 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.

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, 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, 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

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 with status: "ACTIVE" or rotated through POST /v1/keys/:id/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.