API changes: October 7, 2026

← Changelog · October 2026

FIX-1007-1: a server delete that loses the race no longer reports success

Before

A DELETE /v1/infra/servers/{id} for a server whose kind is not GALAXY_APP, arriving while another call was still deleting the same machine, reported success.

After

A delete of such a server that this call actually performed still returns HTTP 200. A call that did not delete that server returns 404 NOT_FOUND, the same as a repeat request for a server that is already gone. For kind=GALAXY_APP the status codes of this route are unchanged. The response remains HTTP 200 when this call performed the delete.

NEW-1007-2: Edit content and publish an individual page block

Added subresources under /v1/pages/:pageId/blocks/:blockId: PATCH /nodes, /styles, /attrs, /tags, PUT /anchor, POST /files, /publication. Requires landing scope; query scope selects the page context. Unknown selectors or indices and empty edits return 400. Class replacement preserves all manifest selector classes. Ineffective text-node values return 400. Write responses contain re-read HTML; Bitrix24 may filter text and attributes. Files accept base64 images only, with a 40 MiB JSON limit. Block publication leaves other page changes in draft.

NEW-1007-3: Knowledge-base bindings to menus and workgroups

Added GET /v1/sites/menu-bindings and GET /v1/sites/group-bindings with optional menuCode and groupId filters, without pagination. POST /v1/sites/:id/menu-bindings and DELETE /v1/sites/:id/menu-bindings/:menuCode change menus for all employees; KNOWLEDGE type is required. URL-encode colons in path menu codes. POST /v1/sites/:id/group-binding changes the site type to GROUP, DELETE /v1/sites/:id/group-binding/:groupId changes it to KNOWLEDGE. Bound pages require scope=GROUP. Write responses read bindings back; group actions also return the site with its new type. The key needs landing scope; READONLY forbids writes. Missing sites return 404 ENTITY_NOT_FOUND, unsupported types 409 SITE_BINDING_TYPE_MISMATCH, unexplained Bitrix24 refusals 422 BITRIX_ERROR.

NEW-1007-4: Block cards and saved templates

Block cards: POST /v1/pages/:pageId/blocks/:blockId/cards/clone, POST /v1/pages/:pageId/blocks/:blockId/cards, DELETE /v1/pages/:pageId/blocks/:blockId/cards/:index with query selector, PUT /v1/pages/:pageId/blocks/:blockId/cards. Writes return current cards: a selector dictionary with arrays of {index,content}. Indexes shift after writes. Rebuilding the entire set accepts selector, non-empty source and values; unknown selectors and indexes return 400 before mutation.

POST /v1/pages/:pageId/blocks/:blockId/favorite with {name,sections?} saves a template in the Bitrix24 account catalog, visible to all editors. Returns {blockId,code}; preview is unsupported. DELETE /v1/block-repository/favorites/:blockId permanently removes a template created by the current user. Missing cards and templates return 404. All routes require landing, accept query scope and refuse writes with READONLY keys.

BC-1007-5: generic lifecycle methods are unavailable for managed agent and bot servers

Old format supported until: 06.10.2026

Before

POST /v1/infra/servers/{id}/start, /stop, and /wake could start and stop a managed agent or bot server through the generic server API.

After

For those servers, the methods return 409 MANAGED_SERVER_LIFECYCLE without contacting the cloud. Manage the agent or bot through its cabinet card. The methods behave as before for ordinary servers and Galaxy Apps.

What integrators should do

Do not call the generic Start/Stop/Wake methods for managed agent or bot servers. Direct users to manage them in the cabinet.

FIX-1007-6: bots recover after a Bitrix24 account address change

Before

After a Bitrix24 account address change, a bot registration could remain bound to the previous address. Recovery required a manual API call, and registration with a new ID could leave Open Channels and WELCOME_BOT bound to the old bot.

After

Vibecode automatically restores the registration after an address change. It first tries to preserve the ID; if that is impossible, it moves Open Channels references to the replacement ID, including WELCOME_BOT. Recovery continues automatically after a temporary failure. An owner request using the old ID receives BOT_ID_REPLACED with the current ID in error.details.botId.

Impact on integrators

No action is required. A client may use error.details.botId if it retained the previous numeric bot ID.

BC-1007-7: a key of an employee marked as dismissed returns 403 OWNER_BLOCKED

Old format supported until: 21.10.2026

Before

When the employee check of a Bitrix24 account found that a key owner had been dismissed in Bitrix24, the key could keep working: V1 calls with it went through, including AI, search, storage, servers and spending the account's credits.

After

While the employee is marked as dismissed, every V1 call with their key gets 403 OWNER_BLOCKED — the same code and text as for a blocked owner. The key is not revoked: as soon as Bitrix24 shows the employee as active again, the key works without reissuing. All of this person's keys in the Bitrix24 account are refused: personal keys, keys of their OAuth apps and keys they gave to deployed apps — for every user of the account. Agents and bots created on their keys stop responding. A Cowork/Code device key that stayed marked as dismissed for more than 60 days may need to be issued again after the mark is lifted.

What integrators should do

If an integration uses the key of a dismissed employee, issue a key on behalf of an active employee of the Bitrix24 account and replace it in the integration. If the mark is wrong, correct the employee's status in Bitrix24 — after the next check the key works again. If the key still does not work after the employee is restored in Bitrix24, contact support. Code reference — Authorization, keys and permissions.

FIX-1007-9: key issuance on an unpaid plan returns 402 with a purchase link

Before

When Bitrix24 refused key issuance because of an unpaid plan, key issuance (POST /v1/keys, POST /v1/apps) failed with a generic issuance error.

After

The response is 402, and error.details.upgradeUrl holds the plan or license purchase link and error.details.secondaryUpgradeUrl an alternative one, when Bitrix24 provides them.

NEW-1007-10: Restore and permanently delete Disk objects

Added POST /v1/files/:id/restore, POST /v1/folders/:id/restore, POST /v1/files/:id/purge and POST /v1/folders/:id/purge with disk scope. Restore returns the object and meta.restored, meta.renamedFrom; a live object returns restored: false. Purge permanently deletes the object, all versions and linked attachments, bypassing trash; folder purge deletes the entire tree and is not transactional. Storage roots cannot be deleted. Ordinary DELETE still moves to trash. Deletion refusal returns 422 DISK_DELETE_REFUSED; unconfirmed restoration returns 422 DISK_RESTORE_REFUSED. Writes are never automatically retried; read the object after a network failure reported as 502 DISK_OUTCOME_UNKNOWN.

NEW-1007-11: Disk full-text search and storage operations

Search accessible Disk through POST /v1/files/fulltext-search: native index query, files and folders, scope and file-type filters, pages of 50 up to offset 1000. Trash is excluded, indexing is asynchronous, and no total match count is returned. POST /v1/storages/:id/folders creates a folder at storage root without looking up parentId. GET /v1/storages/types returns the incomplete Bitrix24 type dictionary.

NEW-1007-12: File version history and content on Drive

Added version history, read, download, restore and upload of a new version into an existing file. Requires disk scope. Another file version returns 404. Download links use authenticated V1 routes. Same-author uploads within about five minutes may overwrite the latest version; restore creates a new version and may evict an old one. Writes are never automatically retried; read the file after an unknown outcome.

NEW-1007-13: Disk public links and folder sharing with a user

Added POST /v1/files/:id/public-link, POST /v1/folders/:id/public-link, POST /v1/folders/:id/shares and GET /v1/folders/access-levels with disk scope. Publication creates or returns a secret link accessible without authentication; storage roots cannot be published. The response includes revocableViaApi:false and meta.inTrash. Trash suspends the link, restoration reopens it, permanent deletion revokes it.

Sharing accepts userId and access:read|add|edit|full, returns 201 and grants rights immediately, before acceptance. With user, user_basic or user_brief scope the recipient is checked before writing; without it meta.recipientVerified:false, Bitrix24 may accept a nonexistent id. Owner and duplicate sharing return 409. Revocation and level changes are unavailable through REST. Access levels return id/code/title; READONLY is allowed only for reading. Writes are never automatically retried; read state first after an unknown outcome. File, folder, sharing, levels.

BC-1007-14: Task stages are checked against the target group kanban

Old format supported until: not provided

Before

PATCH /v1/tasks/:id accepted a stageId from another group or My Plan; older Bitrix24 versions could report success and store an incompatible stage.

After

These requests receive 400 INVALID_PARAMS before writing. When groupId changes in the same request, the new group kanban is checked. For My Plan use POST /v1/tasks/:taskId/move-stage. A zero stageId retains the native choice of the group first column.

What integrators should do

Pass a stageId from the target group kanban. Use the separate move-stage action for My Plan.

NEW-1007-15: Task stage management and day plan reading

You can create group kanban and My Plan stages, update and delete empty stages, move tasks with ordering, read sorting permission and the day plan. Creation without a position appends a column. An explicit first position changes the group default, and reordering may move tasks without task history. Reading the day plan saves truncation to 30 tasks, just as the Bitrix24 widget does. The stagesId filter shows My Plan position independently of the task stageId.

NEW-1007-16: Manage task custom fields

Added GET/POST /v1/userfields/tasks, GET /v1/userfields/tasks/types and GET/PATCH/DELETE /v1/userfields/tasks/:id with task scope. Read schemas and enumeration items with xmlId, create fields and change labels. Fields are shared by all tasks in the account; deletion irreversibly erases values from every task. System fields are protected against writes. PATCH refuses immutable properties, empty changes and list items without values, preserving the previous xmlId when omitted.

BC-1007-17: Warehouse stock records and read-only currency base flag

Old format supported until: not provided

Before

PATCH /v1/currencies/:id accepted base and confirmed the update without changing the base currency.

After

The base field and its BASE alias are read-only: updates return 400 READONLY_FIELD. Change the base currency in the Bitrix24 interface.

Added GET /v1/warehouses/:id/stock/:recordId. A foreign-warehouse, missing or inaccessible row returns 404 ENTITY_NOT_FOUND. Stock and reserve may be null; reserve can exceed stock.

GET /v1/warehouses/:id/stock accepts optional productId to select a product within the warehouse. Invalid identifiers return 400 INVALID_PARAMS. Other filters remain unsupported.

What integrators should do

Remove base from currency updates. Use productId to select a product and take recordId from the stock list to read a row.