API changes: October 20, 2026

← Changelog · October 2026

FIX-1020-1: the reference and OpenAPI show the actual response of five operations

Before

The OpenAPI response schema of GET /v1/users/me listed five fields (id, name, lastName, email, isAdmin), although the call returns the whole user record. Its reference card printed a userType field the response does not carry. The cards of POST /v1/chats/{chatId}/mute, GET /v1/activities/{activityId}/transcript and POST /v1/leads/{id}/convert showed a chat, activity or lead record in the response example and the field list instead of what the operation returns. The POST /v1/crm-documents/{id}/public-url example carried a long link, while Bitrix24 returns a short one.

After

The GET /v1/users/me schema describes the user record fields under the same names as GET /v1/users/{id}, without userType, and allows keys beyond them: WORK_*, some PERSONAL_* keys and the account's UF_* fields arrive in UPPER_SNAKE_CASE. The card prints exactly those fields. The mute, transcript and convert cards show the operation's response: { chatId, muted }, { transcription } and { lead, deal, contact, company }. The public-url example is a short link such as https://<account address>/~a1B2c. The documentation caught up with the actual response: the HTTP 200 response of these operations and its content are unchanged.

Impact on integrators

No client change is needed. A client built from the former card could expect the fields of a chat, activity or lead record, and userType from GET /v1/users/me. They were never in the response and still are not: read the fields the reference now lists.

FIX-1020-2: Neutral server repair error messages

Before

The error field in GET /v1/infra/servers/{id}/repair-status could contain an internal server management error when a repair failed.

After

Server management errors now return a neutral English hint with an incident code. Include this code when contacting support. The DISK_FULL: machine prefix for insufficient disk space is preserved. The response schema and HTTP status codes are unchanged.

FIX-1020-3: Public refusal reasons for bot updates and event polling

This change applies only to PATCH /v1/bots/{botId} and GET /v1/bots/{botId}/events. Bot registration, registration recovery, and resubscription retain their existing contracts.

Before

PATCH /v1/bots/{botId} could return HTTP 409 with an internal refusal reason and Retry-After: 5, even when retrying could not help. GET /v1/bots/{botId}/events built its recovery refusal separately from the shared handler.

After

On PATCH, bot lifecycle refusals use three public classes: BOT_RECOVERY_IN_PROGRESS with Retry-After: 5, BOT_EFFECT_IN_PROGRESS with Retry-After: 30, and BOT_UNAVAILABLE without Retry-After. The last class means that the bot state needs repair through support. Event polling uses the same handler after releasing its poll slot. Its current path only originates the recovery refusal BOT_RECOVERY_IN_PROGRESS with the same five-second wait. An unfinished bot mutation alone does not refuse a poll.

Impact on integrators

For PATCH, use the public class and its retry delay. Shared normalization also protects the poll error boundary, without introducing new refusals for polling. The behavior of BOT_EVENTS_BUSY and BOT_ID_REPLACED responses is unchanged.

FIX-1020-4: marking notifications read accepts an empty body with a JSON header

Before

POST /v1/notifications/read with the Content-Type: application/json header and an empty body was refused with 400 FST_ERR_CTP_EMPTY_JSON_BODY before the request was processed. The same request without the header went through.

After

An empty body and a whitespace-only body sent with the Content-Type: application/json header are handled as {}. The response is the same as for the body {}. A request with no body and no header is still handled as {}, as before. In the format=v2 mode an empty body is checked as a body without the ids field and is refused with 400 INVALID_PARAMS. A body that does not parse as JSON is still refused with 400 FST_ERR_CTP_INVALID_JSON_BODY.

Impact on integrators

No action required. A client that sends the Content-Type: application/json header on every request no longer has to add the body {}.

FIX-1020-5: a Compose deploy names the container that failed behind HTTP 200

Before

POST /v1/infra/servers/{id}/deploy for a Docker Compose rollout could finish as a success when the published port answered HTTP 200, even though a container of the same project was restarting and the API was not staying up. The healthcheck step did not name that container or attach its startup log. The HTTP status of the deploy response itself stayed 200.

After

When a container of the Compose project in the extractTo directory is restarting — even one that has been restarting since before the deploy — or a container started during this deploy has restarted since it started, has exited with a non-zero code, is in the dead state, or is marked unhealthy by Docker, the healthcheck step fails and error.message includes the service name, its state and the container's startup log. A successful deploy whose project containers stay up still returns success: true. For POST /v1/infra/servers/{id}/deploy the HTTP 200 response is unchanged: the failure still arrives in the body as success: false.

FIX-1020-6: key deletion no longer gets stuck after a bot change

Before

If the key's bot had been changed through PATCH /v1/bots/{botId} shortly before deletion, for example to rename it, DELETE /v1/keys/{id} kept answering 409 KEY_BOT_CLEANUP_PENDING. Retrying did not help, and both the key and the bot stayed in place.

After

A bot change made through PATCH /v1/bots/{botId} and already accepted by Bitrix24 no longer blocks deletion: the platform unregisters the bot in Bitrix24 and deletes the key, and the response is 204. A change the platform has not finished yet — its Bitrix24 response has not arrived, or work on the change is still going on — keeps answering 409 KEY_BOT_CLEANUP_PENDING until it completes.

The exception is a change that gives the bot a new token: a request carrying the fields.botToken field, or a switch to webhook mode in which the platform issues the new bot token itself. Until such a change is finished, the response stays 409 KEY_BOT_CLEANUP_PENDING, and repeating the request does not change that.

Impact on integrators

No action required. Keys whose deletion got stuck after an ordinary bot change are deleted by repeating the request. If unregistering the bot in Bitrix24 failed, or the last bot change replaced the bot token, the response stays 409 KEY_BOT_CLEANUP_PENDING.

NEW-1020-7: Company connections: readiness checks at every phase

At /v1/connect/authorize and /v1/connect/token, CREATE and RECONNECT require enabled access and verified readiness. CONNECT_COMPANY_DISABLED and CONNECT_COMPANY_NOT_READY return no secret. CONNECT_COMPANY_ATTEMPT_LIMITED includes Retry-After.

CREATE returns the secret once. RECONNECT preserves it and returns credential_unchanged: true without api_key. ROTATE_SECRET works for an existing connection while new issuance is disabled, checks credential_version and returns the new secret once. Replaying a code returns invalid_grant. bitrix_ready reflects actual request availability, including pending deletion of old webhooks. AI and other vibe:* scopes are not supported for Company connections yet.

NEW-1020-8: AI for company connections with separate administrator consent

COMPANY connections support vibe:ai when AI access is enabled for the Bitrix24 account and administrator and the app allows the scope. On CREATE and when RECONNECT first adds AI, the administrator explicitly selects additional consent. Without it, connection setup does not begin: CONNECTION_SCOPE_CONSENT_REQUIRED.

After each CREATE or RECONNECT with AI consent, the service attempts to create a separate AI permission if none exists. If saving it fails, the successful /v1/connect/token response and key delivery are preserved; an administrator can retry by reconnecting the company with AI consent. Check availability through capabilities.ai in connection status. An administrator can restore revoked permission in the Bitrix24 account AI settings. RECONNECT does not restore it; revocation does not disable Bitrix24 access. vibe:storage remains unavailable for COMPANY.

FIX-1020-9: account cleanup fixed for deletion of apps without placement permission

Before

After DELETE /v1/apps/:id, a cloud application without the placement permission could remain in Bitrix24, and cleanup retries stopped after several failed attempts.

After

Cleanup of such an application can use its verified creator's developer key. The application is unregistered only after a complete check and confirmed placement removal. If verification cannot be completed, retries continue at intervals of up to one day. The response remains HTTP 204 No Content: it confirms deletion in Vibecode and revocation of the paired API key, while Bitrix24 cleanup may continue in the background.

Impact on integrators

No changes to requests or HTTP status handling are required.

FIX-1020-10: updating a bot after an acknowledged write

Before

If Bitrix24 acknowledged a bot update but the new name did not appear on read, later PATCH /v1/bots/{botId} requests could keep returning 409 BOT_EFFECT_IN_PROGRESS.

After

The platform reapplies the acknowledged update and verifies the result. Once the name matches, the next PATCH /v1/bots/{botId} succeeds again; the successful response shape is unchanged.

FIX-1020-11: a storage key with an empty or "." segment is rejected at the entry

Before

POST /v1/storage/objects/upload and POST /v1/storage/objects/multipart/create accepted a key such as docs//a.txt, docs/./a.txt or docs/a/.: the key check caught only .., so an extra separator and a . segment went into the object path.

After

Such a key is rejected the same way as a key with ..: response 400 with code STORAGE_INVALID_KEY, no object is created. Keys without empty segments and without . and .. segments work as before.

Impact on integrators

If a key is built by joining parts, drop the extra separator and . segments before sending it.

FIX-1020-12: Batch product creation returns product identifiers

Before

Successful product creation through POST /v1/catalog-products/batch could omit id from data.results. Accessing the created product required a separate search.

After

With action: "create", results return the numeric id received when the corresponding product was created. index links each result to its input array item. The data.summary format and failure handling are preserved.

FIX-1020-13: reading and copying a sleeping application's database

Before

A closed WAL database without -wal and -shm files returned APP_DB_WAL_CLOSED even for a sleeping application. This blocked database browsing, backups, and restoration, which requires a protective copy of the current data.

After

When the application is confirmed stopped, its closed database can be read and copied without waking the application. The fix affects GET /v1/infra/servers/{id}/db, GET /v1/infra/servers/{id}/db/schema, GET /v1/infra/servers/{id}/db/tables/{table}/rows, POST /v1/infra/servers/{id}/db/query, POST /v1/infra/servers/{id}/db/backups and POST /v1/infra/servers/{id}/db/restore, including the protective copy before restoration.

A running application with a closed WAL database still receives APP_DB_WAL_CLOSED: its database connection must remain open. If the application wakes during a read or copy, the result is discarded with APP_DB_BUSY; the operation can be retried.

BC-1020-14: A new version of an existing app requires the same access as a new app

Old format supported until: not provided

Before

POST /v1/infra/servers/:id/deploy and POST /v1/infra/servers/:id/upload checked only the key and the rights to the server. A Bitrix24 account whose commercial plan had ended was refused when creating a new app but kept delivering new versions of an app it already had.

After

Both calls answer with the same refusal as creating a new app: 402 INT_TARIFF_REQUIRED, 402 INT_VIBE_PLUS_REQUIRED where access is narrowed to the Vibe+ plan line, or 403 PORTAL_TARIFF_UNREADABLE when the plan could not be read. The body is the same as for creating an app: userMessage, alternatives and hint. When a purchase clears the refusal, error.details.upgradeUrl carries the upgrade link. When the platform could not read the plan, there is no purchase link: error.details.remedy is refresh_tariff, and alternatives holds the recheck via GET /v1/me?refresh=tariff. The check comes first, before the server is woken and before the archive is accepted, so the refusal leaves nothing behind and carries no operation id. The app that is already running keeps responding; commands on the server, logs and source downloads stay available.

What integrators should do

Handle these codes on delivery the same way as on app creation and pick the action by error.details.remedy. When it is refresh_tariff, call GET /v1/me?refresh=tariff and repeat the delivery: once the platform reads the plan, the retry can pass. Otherwise show the person userMessage and the path from alternatives; a retry without changing the plan returns the same answer. The state is visible in advance in capabilities.servers.deploy in GET /v1/me. The slot is built from the stored plan, so right after a purchase it can answer false a little longer than the delivery itself.

FIX-1020-15: Explicit bitrix-search selection in the research schema

Before

The OpenAPI schema for POST /v1/research omitted bitrix-search from the allowed provider values, although this choice could support research.

After

bitrix-search is included. Its research availability depends on the provider's current capabilities: check capabilities.modes.research in GET /v1/search/providers. Access conditions and credential requirements still apply.

Impact on integrators

Clients validating request bodies against OpenAPI can explicitly select bitrix-search. Previous values and omission of provider remain supported.

BC-1020-16: Quick replies accept only sections of their own channel

Old format supported until: not provided

Before

POST /v1/openline-configs/:lineId/quick-replies and PATCH /v1/openline-configs/:lineId/quick-replies/:id accepted a sectionId of another channel's section or of a non-existent section and returned a successful response. Such a quick reply did not appear in any channel's list, and it could not be updated or deleted through the API.

After

A sectionId other than 0 is checked against data.sections of this channel's quick reply list. A section outside the list is rejected with 400 INVALID_PARAMS, and nothing is created or changed. PATCH still accepts the reply's current section. If the channel's quick replies are unavailable to the key user, POST with sectionId returns 403 BITRIX_ACCESS_DENIED. Requests without sectionId or with 0 work as before.

What integrators should do

Take sectionId from data.sections in the GET /v1/openline-configs/:lineId/quick-replies response of the same channel, or pass 0 to create a reply without a section.

NEW-1020-17: Connector list pages, search and filters

Connector list GET /v1/connectors accepts cursor, limit from 1 to 100, q, category, scope, type, view=mine, mode, and sort. A request with list parameters returns nextCursor, total, group counts, and truncated: another page is available while it is true. mode is accepted without filtering until mode data is available; type=own returns an empty list. The popular sort currently uses title order. Without parameters, item fields and slug order are preserved; only truncated is added.

BC-1020-18: activity update refuses the deadline instead of answering without a change

Old format supported until: not provided

Before

PATCH /v1/activities/:id with a deadline field in the body returned 200 with success: true, but the activity deadline did not change: the response and a repeated read kept the previous deadline. A batch update POST /v1/activities/batch with action: "update" behaved the same way.

After

An update request with deadline returns 400 READONLY_FIELD and applies none of the body fields. The error.hint in the response points to POST /v1/activities/:id/deadline. A batch update refuses such an item with 400 BATCH_ITEM_VALIDATION. In the GET /v1/activities/fields response the deadline field is marked readonlyOnUpdate: true. Creating an activity with deadline is unchanged.

What integrators should do

Remove deadline from the update body and change the deadline with POST /v1/activities/:id/deadline, or shift it by a given amount of time with POST /v1/activities/:id/postpone. Send the other fields in PATCH as before.

NEW-1020-19: Connectors report their type and session modes

GET /v1/connectors returns type: "connector" and modes in every item: the supplier-supported cowork and code session modes. Both modes are available by default, including for previously published connectors. Existing fields and list order are preserved; mode still describes read or write access.

NEW-1020-20: node24 runtime on a supported Node.js release

The GET /v1/infra/runtimes catalog adds the node24, node24-pg, node24-mysql, node24-redis, node24-mysql-redis, node24-pg-redis and node24-rag runtimes. They come first in the list, and node24 is the runtime offered to new Node.js apps: Node.js 20 reached end of life on 2026-04-30. In Galaxy the runtime is built from the official node:24-slim image. On a dedicated virtual machine every deploy installs the latest 24.x release from the official Node.js archive and verifies the Node.js release team's signature. The node20* runtimes stay in the catalog and work as before. Every catalog entry now carries deprecated and replacement: for node20* they are true and the ID of the successor with the same package set, for example node24-pg for node20-pg, and false and null for every other runtime.

NEW-1020-21: replace an application's server through the API

Added GET /v1/applications/{id}/available-servers and POST /v1/applications/{id}/replace-server. The first returns the card owner's servers the application can move to, and a canCreateNew flag that says whether a new server can be created. When it cannot, createNewBlocked gives the reason. The client can use the response to decide up front whether to show a replace button.

The second moves the application to an existing server ({ "serverId": "…" }) or creates a new one ({ "provider": "…", "plan": "…", "region": "…" }, the same values as POST /v1/infra/servers). The old server is not deleted and stays with its owner. The key of the call is not reassigned: callerKeyManagesServer says whether that key manages the server. If a failure happens after the application is moved, the response stays 200 and the problems are listed in warnings: KEY_ASSIGN_FAILED, APP_URL_MOVE_FAILED, APP_URL_MANUAL, CATALOG_STALE, SERVER_KEY_STALE.

Only the card owner can replace the server.

The server sleep mode is switched with the existing PATCH /v1/infra/servers/{id}/run-mode.

NEW-1020-22: Connector selection for Cowork

Optional ASCII headers X-Cowork-Connectors-Enabled and X-Cowork-Mode on every request to POST /v1/connectors/mcp narrow the connector set and select cowork or code. Filtering applies before the direct-tool threshold, during discovery and direct/meta calls. Invalid headers return 400 INVALID_BODY; omitting both headers preserves the response. Connection setup and settings remain in the web cabinet.

The card GET /v1/connectors/{slug} shows published tools with readOnly, separate service company and publisher, modes and safe state. Account-blocked connectors are hidden even from administrators.

BC-1020-23: PHP 8.3 on a dedicated server is installed from the Ubuntu repository

Old format supported until: not provided

Before

POST /v1/infra/servers/:id/deploy with runtime php83 or php83-mysql added the third-party ppa:ondrej/php repository on a dedicated server and installed PHP 8.3 from it. If that repository was unreachable, the runtime install could fail.

After

On a new server PHP 8.3 is installed from the standard Ubuntu 24.04 repository: version 8.3.6 with Canonical security fixes. The php8.3 command, the php8.3-fpm service and Composer stay the same. Servers that already have the PPA are not affected.

What integrators should do

If the app's composer.json requires "php": ">=8.3.7" or higher, relax the constraint to ^8.3: otherwise composer install fails on a new server. API requests need no changes. Servers that already have the PPA are not affected.

NEW-1020-29: Official connector marker in catalog pages

When requesting the connector list with list parameters, each item includes verified, the official catalog connector marker. The card returns the same marker.

NEW-1020-30: Service company and connector modes in the workshop

When creating or editing a connector, authors can set its service company separately from the publisher and select Cowork and Code modes. Service-company fields can be cleared; saving requires at least one mode.

NEW-1020-31: Service companies in the connector catalog

Service companies are stored separately from publishers and configured through the workshop API. Cards, cabinet lists and host lists return the company, and server search includes its name. Existing connectors without configured company metadata return null.

FIX-1020-32: Connector group counts in Cowork

The available count matches the server-selected group. Informational rows for previously connected services disabled by an administrator stay in the Cowork tab and are excluded from that group and its count.

FIX-1020-33: Retry-After of a bot reconcile refusal is the time until the next scheduled check

Before

While a bot change was waiting to be reconciled with Bitrix24, a repeated POST /v1/bots with the same code got 409 with a Retry-After: 5 header, and other bot changes got 409 BOT_EFFECT_IN_PROGRESS with Retry-After: 30. Every repeat contacted Bitrix24 again, even when the next scheduled check was minutes away. A repeated DELETE /v1/bots/:botId while an earlier deletion of the same bot was still being reconciled answered as a Bitrix24 refusal: 502 BOT_DELETE_PARTIAL without Retry-After (with ?force=true, 409 BOT_DELETE_PENDING with Retry-After: 5), and made an extra check call to Bitrix24.

After

The Retry-After header of such a refusal carries the time until the next scheduled check of the record, at most 300 seconds. A repeat before that time gets the same refusal without contacting Bitrix24. The error codes and the 409 status are unchanged. In this case DELETE /v1/bots/:botId, with or without ?force=true, returns 409 BOT_EFFECT_IN_PROGRESS with Retry-After, does not contact Bitrix24 and keeps the bot record. A refusal from Bitrix24 itself still returns 502 BOT_DELETE_PARTIAL or 409 BOT_DELETE_PENDING.