# API changes: October 8, 2026 [← Changelog](/docs/changelog) · [October 2026](/docs/changelog/2026-10) ### FIX-1008-1: Python 3.11 installation continues when the package repository is unavailable **Before** Deploying a standalone server with the Python 3.11 runtime could fail when the package repository did not respond. **After** Python 3.11 installation tries a verified fallback source. After a successful deployment, `python3.11` and `pip` for Python 3.11 are available; the system `python3` remains unchanged. ### FIX-1008-2: User SSH keys are installed on pre-provisioned virtual machines **Before** `POST /v1/infra/servers` could assign a pre-provisioned virtual machine without installing the user key supplied in `sshPublicKey`. **After** On successful creation, the platform installs that key on a pre-provisioned machine too. You can use your own key to connect over SSH; the SSH key fields in the response still contain the platform's key. ### FIX-1008-4: OpenAPI describes reading mail messages, acting on them and finding recipients **Before** Eight working mail methods were missing from OpenAPI and the VibeCode API reference: [reading a message](/docs/mail/messages/get), [the message thread](/docs/mail/messages/thread), [moving messages](/docs/mail/messages/move), [reply](/docs/mail/messages/reply) and [forward](/docs/mail/messages/forward), creating a [task](/docs/mail/conversions/task), an [event](/docs/mail/conversions/calendar-event), a [chat](/docs/mail/conversions/chat), a [post](/docs/mail/conversions/feed-post) and a [CRM activity](/docs/mail/conversions/crm-activity-create) from a message, [removing the CRM activity](/docs/mail/conversions/crm-activity-delete), finding [contacts](/docs/mail/recipients/contacts) and [employees](/docs/mail/recipients/employees) to address. Client generators and agents reading the specification could not see these methods. **After** The methods are included in the full specification, the `mail` slice and both reference languages. Their behaviour is unchanged. Regenerate your client from the current specification to expose the methods. **Integrator impact** No action is required. ### FIX-1008-5: OpenAPI describes organizational structure counts, searches and operations **Before** Ten working organizational structure methods were missing from OpenAPI and the VibeCode API reference: [employee count](/docs/humanresources/employees/count), [employee subordinates](/docs/humanresources/employees/subordinates), [employee search](/docs/humanresources/employees/search), [employees in several departments](/docs/humanresources/employees/multidepartment), [node count](/docs/humanresources/node-operations/count), [child nodes](/docs/humanresources/node-operations/children), [reading](/docs/humanresources/node-operations/communications-get) and [configuring communication tools](/docs/humanresources/node-operations/communications-set), node membership operations — [adding](/docs/humanresources/members/add), [removing](/docs/humanresources/members/remove), [moving](/docs/humanresources/members/move) and [replacing members](/docs/humanresources/members/set), and [moving a node](/docs/humanresources/node-operations/move). Client generators and agents reading the specification could not see these methods. **After** The methods are included in the full specification, the `humanresources` slice and both reference languages. Their behaviour is unchanged. Regenerate your client from the current specification to expose the methods. **Integrator impact** No action is required. ### FIX-1008-6: OpenAPI describes your AI provider keys and their models **Before** Eleven working AI provider key methods were missing from OpenAPI and the VibeCode API reference: [listing keys](/docs/ai/credentials/list), [connecting](/docs/ai/credentials/create), [updating](/docs/ai/credentials/update), [deleting](/docs/ai/credentials/delete), [testing](/docs/ai/credentials/test), [usage statistics](/docs/ai/credentials/usage), [fetching models](/docs/ai/credentials/fetch-models), [listing models](/docs/ai/credentials/models-list), [adding a model](/docs/ai/credentials/models-add), [deleting a model](/docs/ai/credentials/models-delete) and [listing providers](/docs/ai/credentials/providers). Agents and client generators reading the specification could not discover these methods. **After** The methods are included in the full specification, the `vibe:ai` slice and both reference languages. Request fields, responses and refusals are described; provider key secrets are never returned in responses. The methods behave as before. Regenerate your client from the current specification to expose them. **Integrator impact** No action is required. ### BC-1008-7: a partner application key does not pass vibe:ai on to a derived key — 403 SCOPE_GRANT_REQUIRES_CONSENT > Old format supported until: not provided **Before** A key issued to a partner application through Partner Connect with the `vibe:ai` scope could create an application through `POST /v1/apps` with `vibe:ai` in `scopes` or add `vibe:ai` through `PATCH /v1/apps/:id`, and the application's paired key received the scope. **After** `POST /v1/apps` and `PATCH /v1/apps/:id` with `vibe:ai` from a partner application key answer `403 SCOPE_GRANT_REQUIRES_CONSENT`, `error.details.unconsented` carries `["vibe:ai"]`, and nothing is created or changed. A paired key created by a partner key does not receive `vibe:ai`. Employee keys and the Cowork/Code device key are not affected. **What integrators should do** Do not request `vibe:ai` for applications created by a Partner Connect key: call the models with the Partner Connect key itself. Reference — [Create an application](/docs/apps/create). ### NEW-1008-8: Partner Connect: a "Connect AI" button example for an application inside Bitrix24 The [Partner Connect](/docs/partner-connect#connecting-ai-from-an-application-inside-bitrix24) page now has a ready-made example: a button in the application frame opens the consent page in a separate browser window, and the frame takes the result from its own server. The consent page cannot be embedded in a Bitrix24 account frame. A heads-up for partners: an application key issued through Partner Connect will stop managing external model keys — `/v1/ai/credentials` with its nested routes and `/v1/ai/providers` will answer it with `403 INSUFFICIENT_SCOPE`. Model calls with the same key do not change. For now these routes respond as before; a separate changelog entry will announce the switch date. ### FIX-1008-10: OpenAPI describes requisite preset fields **Before** Seven working requisite preset field methods were missing from OpenAPI and the VibeCode API reference: [listing fields](/docs/entities/requisite-presets/preset-fields/list), [schema](/docs/entities/requisite-presets/preset-fields/schema), [available fields](/docs/entities/requisite-presets/preset-fields/available), [adding](/docs/entities/requisite-presets/preset-fields/create), [reading](/docs/entities/requisite-presets/preset-fields/get), [updating](/docs/entities/requisite-presets/preset-fields/update) and [deleting](/docs/entities/requisite-presets/preset-fields/delete). Agents and client generators reading the specification could not discover these methods. **After** The methods are included in the full specification, the `crm` slice and both reference languages. Parameters, request fields, responses and refusals are described. The methods behave as before. Regenerate your client from the current specification to expose them. **Integrator impact** No action is required. ### FIX-1008-11: Disk method availability **Before:** requests to `/v1/disk/*` could return `403 DISK_FEATURE_DISABLED` with a valid key carrying the `disk` scope. **After:** methods are available without separate platform activation. Authentication, the `disk` scope, current access checks and key access mode still apply. Check search, sync and save support through `GET /v1/disk/capabilities`. ### BC-1008-12: forced bot deletion requires Bitrix24 confirmation > Old format supported until: not provided **Before** [DELETE /v1/bots/{botId}](/docs/bots/management/delete) with `force=true` could return HTTP 200 and remove the bot record even when deletion in Bitrix24 was unconfirmed. **After** If deletion in Bitrix24 is unconfirmed, the response is HTTP 409 `BOT_DELETE_PENDING` with `Retry-After`. The bot record remains available for another attempt. The successful HTTP 200 response remains unchanged when deletion is confirmed. **What integrators should do** On `BOT_DELETE_PENDING`, keep treating the bot as registered; retry after `Retry-After` and wait for a successful response. ### FIX-1008-13: key deletion waits for bot cleanup **Before** `DELETE /v1/keys/{id}` returned `409 KEY_HAS_LINKED_AGENT` when the key had a standalone bot. Deleting the bot required a separate request. **After** For a key without a live agent or managed bot, deletion starts cleanup of the linked Bitrix24 bot. Until cleanup is confirmed, the response is `409 KEY_BOT_CLEANUP_PENDING`; the key and bot remain available. Retry the request after cleanup completes. ### BC-1008-14: single-entity batch list applies the sort order > Old format supported until: not provided **Before** The `list` action of [POST /v1/{entity}/batch](/docs/entity-api) did not read `sort` or `order`. A sub-call with a sort succeeded, but rows came back in the Bitrix24 order, ascending by `id` for deals and other CRM entities. No error or warning was returned. The same order sent through the global `POST /v1/batch` was applied for these entities. **After** A `list` sub-call reads `sort` and `order`, translates both spellings into Bitrix24 field names and passes the order to Bitrix24. When both are sent, `sort` sets the order and `order` is still validated. A sort the entity cannot accept is rejected with an error in its own sub-call before any Bitrix24 call, and neighboring sub-calls still run: an invalid direction gives `INVALID_SORT_DIRECTION`, an unknown field on entities whose sort-name validator is active gives `UNKNOWN_SORT_FIELD`, and a sort on entities that do not support one in a sub-call (`departments`, `telephony-lines`, `calendar-resources`, `calendar-events`, `doc-templates`) gives `INVALID_SORT_FIELD`. Document templates are sorted by the single `GET /v1/doc-templates?sort=…`, and calendar events come back ordered by start time. For `users` the order is sent as a single field, and the `SORT_FALLBACK_TO_ID` warning applies as in the global batch. **What integrators should do** If a sub-call sent a sort that is now rejected, fix the direction or the field name, and drop the parameter on entities without sorting: it was never applied. Sub-calls without a sort work as before. There is no parallel support for the old behavior: the parameter was silently ignored, so there is nothing to keep.