API changes: October 8, 2026

← Changelog · October 2026

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, the message thread, moving messages, reply and forward, creating a task, an event, a chat, a post and a CRM activity from a message, removing the CRM activity, finding contacts and 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, employee subordinates, employee search, employees in several departments, node count, child nodes, reading and configuring communication tools, node membership operations — adding, removing, moving and replacing members, and moving a node. 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, connecting, updating, deleting, testing, usage statistics, fetching models, listing models, adding a model, deleting a model and listing 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.

NEW-1008-8: Partner Connect: a "Connect AI" button example for an application inside Bitrix24

The Partner Connect 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, schema, available fields, adding, reading, updating and deleting. 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} 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 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.