# API changes: October 23, 2026 [← Changelog](/docs/changelog) · [October 2026](/docs/changelog/2026-10) ### FIX-1023-1: the 502 hint for a galaxy in ERROR that never connected no longer advises a retry **Before** [POST /v1/infra/servers/:id/deploy](/docs/infra/deploy/deploy) and [DELETE /v1/infra/servers/:id](/docs/infra/servers/delete) for a galaxy app whose galaxy virtual machine failed to come up and stayed in the `ERROR` status answered `502 GALAXY_HOST_UNREACHABLE` with an `error.hint` that said to wait 1–2 minutes, repeat the same request and not delete the slot. The retry never helped, and the delete response also said "try again shortly". **After** For a galaxy in the `ERROR` status whose tunnel never connected (`blackholeStatus` is `NONE`), the response code stays `502 GALAXY_HOST_UNREACHABLE`, but the `error.hint` fields say plainly that a retry will not help. A galaxy that never started is retired by the platform's background cleanup together with the app slot, after which requests to the app id answer `404`, and you create the app again. If the slot is still there after a day, start the galaxy from the dashboard or contact support. In every other case the hint is unchanged, including a galaxy in `ERROR` that has connected before: a retry or a start brings it back. Details are in the [Galaxies](/docs/infra/galaxy) section. **Impact on integrators** Do not repeat the deploy or the deletion when `error.hint.reason` says the galaxy is in the `ERROR` status and its tunnel never connected: wait for the slot to be removed and create the app again. ### NEW-1023-2: Submit a CRM form result and send a form to an Open Channel customer `POST /v1/crm-forms/:id/results` submits visitor values and returns `201` with `data.resultId`. Bitrix24 may create CRM records, run automation and notify responsible users. `POST /v1/openlines/sessions/send-form` takes `sessionId` and `formId`, resolves form codes and returns `200` with `data.sent`. This sends a customer message, not a delivery confirmation. Both routes require READWRITE; sending to a dialog requires `imopenlines` and `crm` scopes. ### FIX-1023-3: GET /v1/me guidance respects Cowork key restrictions **Before** The `GET /v1/me` response for a key carrying the `vibe:cowork` scope suggested application and server management operations that the key could not perform. **After** The response remains HTTP 200. Rules, server recovery advice and embedding instructions respect the key restrictions: instead of operation addresses returning `403 INFRA_FORBIDDEN_FOR_COWORK_KEY`, they point to the available path in `deployment` or a user action. Guidance for keys without `vibe:cowork` is preserved. ### FIX-1023-4: Deployment to a new or woken server survives system updates **Before** [POST /v1/infra/servers/:id/deploy](/docs/infra/deploy/deploy) with runtime installation on a just-created or just-woken server could end with `DEPLOY_TIMEOUT` after about 330 seconds: an automatic system update restarted the network, and the runtime installation was cut off together with the connection. **After** Before runtime installation, the readiness check waits for system updates to finish within the existing 15-minute preparation budget. During the first hour after a server is created or woken, runtime installation survives a temporary connection loss, and its outcome is read back once the connection recovers. If the outcome cannot be confirmed, the deployment still answers `DEPLOY_TIMEOUT`, in the worst case about 390 seconds after installation started. The readiness timeout message names the cause `APT_BUSY` when the server was still installing updates. **Impact on integrators** Requests require no changes. JSON and SSE formats and error codes are preserved. Runtime installation is still sent to the server once and is never repeated. ### BC-1023-5: CRM forms: configuration reads and builder dictionaries > Old format supported until: not provided **Before** `GET /v1/crm-forms` returned only id and name without pagination; `meta.total` held the response size. `GET /v1/crm-forms/:id` returned a limited form projection; person-name field types were `name`, `last-name`, `second-name`, and visibility and agreement labels came from the previous contract. **After** The list supports name, code, entityScheme, responsibleUserId, createdTime/updatedTime ranges and limit/offset up to 1000. Rows add code, active, system, createdTime and updatedTime. Bitrix24 supplies no total count: `meta.total` is omitted. `isCallback` filters the selected page. The form retains legacy keys and adds configuration blocks. Person-name `fields[].type` is now `string`; `fields[].visible` is always `true` because the new contract does not publish visibility. `agreements[].name` retains `AGREEMENT_`, while `agreements[].label` is now `null`: the CRM contract does not provide label text. The full agreement block is available as `agreementsSettings`. Fields add sort, valueType and value; list options remain in items. New routes: `GET /v1/crm-forms/configuration`, `/v1/crm-forms/scenarios`, `/v1/crm-forms/scenario-categories`, `/v1/crm-forms/entity-fields?entityName=LEAD`, `/v1/crm-forms/fields`, `/v1/crm-forms/fields/:name`. They read builder settings and dictionaries. Analytics, integrations and spam protection are excluded. **What integrators should do** Page through the list using limit/offset; do not treat meta.total as a collection size. Treat string as the person-name field type; do not use visible to identify hidden fields. Handle nullable agreement labels. Bitrix24 refusals retain the original reason; an absent form returns `404 ENTITY_NOT_FOUND`. ### FIX-1023-6: a request to a bitrix model without images no longer hits the limit for images **Before** [POST /v1/chat/completions](/docs/ai/chat/completions) with a `bitrix/*` model measured any body against the same limit as a body with images, and refused a long message history without images with `413 ai_payload_too_large`. **After** A body without images is measured against its own, higher model cluster limit and is sent to the model. A body with images is measured against the same limit as before, and the platform still downscales the `data:` images in it itself. When a body without images does not fit its limit, the response is `413 ai_payload_too_large`: the message states the request size and the limit in effect, and advises shortening the message history rather than downscaling images. **Impact on integrators** No action is required. Requests that went through before work as before. Details — [image analysis](/docs/ai/chat/vision). ### FIX-1023-7: unsupported GET collection filters now return a warning **Before** The GET endpoints listed below ignored the generic `filter` parameter and returned a broader collection without explaining why. **After** These endpoints preserve the previous successful response and the same data. When a generic `filter` is unsupported, the response includes `Warning: 299 - "filter is not supported on this endpoint and was ignored"`; the server records its use. For `/v1/chats/recent` and `/v1/chats/:dialogId/users`, this applies to the legacy branch. `format=v2` keeps its existing strict validation. **Affected endpoints:** - [GET /v1/activities/:activityId/bindings](/docs/entities/activities/bindings/list) - [GET /v1/bots/:botId/events](/docs/bots/events) - [GET /v1/bookings/:id/clients](/docs/entities/bookings/clients-list) - [GET /v1/booking-wait-list/:id/clients](/docs/entities/booking-wait-list/clients-list) - [GET /v1/calendar-resources/bookings](/docs/entities/calendar-resources/bookings) - [GET /v1/calendar/accessibility](/docs/calendar/accessibility) - [GET /v1/catalog-products/:productId/images](/docs/entities/catalog-products/images-list) - [GET /v1/chats/events](/docs/chats/events) - [GET /v1/chats/:dialogId/users](/docs/chats/members/list) - [GET /v1/chats/recent](/docs/chats/discovery/recent) - [GET /v1/crm-deliveries](/docs/entities/crm-deliveries/list) - [GET /v1/crm-documents](/docs/entities/documents/crm-list) - [GET /v1/crm-payments/:id/products](/docs/entities/crm-payments/products-list) - [GET /v1/crm-payments/available-products](/docs/entities/crm-payments/available-products) - [GET /v1/humanresources/nodes/:id/children](/docs/humanresources/node-operations/children) - [GET /v1/humanresources/nodes/:id/communications](/docs/humanresources/node-operations/communications-get) - [GET /v1/infra/servers/:id/b24-users](/docs/infra/access/b24-users) - [GET /v1/mail/mailboxes/:id/senders](/docs/mail/mailboxes/senders) - [GET /v1/mail/messages/:id/thread](/docs/mail/messages/thread) - [GET /v1/me/workgroups](/docs/me/workgroups) - [GET /v1/note/collections](/docs/note/collections/list) - [GET /v1/note/collections/:collectionId/documents](/docs/note/collections/tree) - [GET /v1/note/documents](/docs/note/documents/list) - [GET /v1/note/documents/search](/docs/note/documents/search) - [GET /v1/openline-configs/:lineId/quick-replies](/docs/openlines/quick-replies/list) - [GET /v1/openlines/crm/chats](/docs/openlines/crm-chats) - [GET /v1/openlines/operators](/docs/openlines/operators) - [GET /v1/posts](/docs/feed/posts/list) - [GET /v1/scrum/epics](/docs/scrum/epics/list) - [GET /v1/scrum/sprints](/docs/scrum/sprints/list) - [GET /v1/scrum/sprints/:sprintId/stages](/docs/scrum/stages/list) - [GET /v1/stage-history](/docs/stage-history) - [GET /v1/tasks/:taskId/chat/messages](/docs/entities/tasks/chat) - [GET /v1/tasks/:taskId/dependencies](/docs/entities/tasks/dependencies-list) - [GET /v1/timeline-logs](/docs/timeline-logs/logs/list) - [GET /v1/triggers](/docs/automation/triggers/list) - [GET /v1/workday/time-control/reports](/docs/workday/time-control-reports) - [GET /v1/workday/time-control/users](/docs/workday/time-control-users) - [GET /v1/workgroups/:groupId/users](/docs/entities/workgroups/users) **Transition plan** Use the endpoint's named parameters or filter the existing response in your application. Integrators will be notified and given time to migrate before strict rejection could be enabled; no switch date is set. ### FIX-1023-8: Bitrix model availability reflects configured access **Before** Standard Bitrix models without configured access were advertised by [GET /v1/models](/docs/ai), but a generation request returned an internal error. **After** These models are no longer advertised in the list. A direct generation request without configured access returns `402 ai_credentials_not_configured` instead of an internal error. **Impact on integrators** Models with configured access remain available for generation. Choose an available model from the list or configure access to Bitrix. ### FIX-1023-9: web search citations match the returned sources **Before** A [POST /v1/search](/docs/search/run) response through `bitrix-search` could retain citations `[6]` and `[7]` in `answer` while `results` contained only five sources with `id` 1–5 because of `max_results`. The response stayed HTTP 200. **After** When normalizing a `[sourceId:N]` marker, citation `[N]` appears in the final `answer` only if a source with that `id` is in the returned `results`. Otherwise the marker is removed. This applies to both the regular response and the final `done` event. The result count remains limited by `max_results`. The response remains HTTP 200. **Impact on integrators** Requests need no changes. The returned sources and their identifiers remain the same. Only the citation is removed, while the statement text stays. Intermediate `answer_delta` events remain unchanged, so use `done.answer` as the final stream text. ### BC-1023-10: V1 operation limits use the authenticated access key > Old format supported until: not provided **Before** Server creation, SSH access, sleep, wake schedule and port settings, server job mutations, application or server source uploads, application blueprint retrieval, source listing and task-comment file downloads shared a limit between different keys using one IP address. Requests without a valid key also spent this limit, while changing the IP address granted a fresh budget. **After** These operations count requests separately for each authenticated key. Different keys using one address have independent budgets, while one key using different addresses shares the operation budget. Requests with a missing or invalid key that reach authentication receive HTTP 401 and do not spend the route budget. Each route limit keeps its threshold and window; overall request limits still apply. `HEAD /v1/me/sources` is no longer supported and returns HTTP 404. [GET /v1/me/sources](/docs/source-storage/registry) remains available with the same response format. **What integrators should do** Use GET instead of `HEAD /v1/me/sources`. No request changes are needed for the other operations listed above. On HTTP 429, follow Retry-After; changing the address does not reset the key budget. ### BC-1023-11: Calendar event batch lists reject from, to and section in params > Old format supported until: not provided **Before** The `list` action in [POST /v1/calendar-events/batch](/docs/entities/calendar-events) silently dropped direct `params.from`, `params.to` and `params.section`. The sub-call succeeded, but without these constraints. **After** A sub-call with any of these keys gets the error `UNSUPPORTED_BATCH_LIST_PARAM`. Sibling sub-calls continue, and the batch response remains HTTP 200. **What integrators should do** Remove `from`, `to` and `section` from batch sub-calls. To select events by period or section, use the single [GET /v1/calendar-events](/docs/entities/calendar-events) endpoint. ### FIX-1023-12: Calendar event and section batch lists forward required parameters **Before** The `list` action in [POST /v1/calendar-events/batch](/docs/entities/calendar-events) and [POST /v1/calendar-sections/batch](/docs/entities/calendar-sections) dropped required `type` and `ownerId` from `params`. The same keys in `params.filter` caused `UNSUPPORTED_FILTER`. **After** Both forms forward `type` and `ownerId` to the Bitrix24 method. A missing, empty or non-scalar required value gives the affected sub-call `MISSING_REQUIRED_PARAMS`. Sibling sub-calls continue, and the batch response remains HTTP 200. Reference examples show a working `list` action. **Impact on integrators** Pass `type` and `ownerId` in `params` or `params.filter`. ### NEW-1023-13: Create, update and manage CRM forms CRM forms can be created, updated, validated, activated, deactivated and deleted through [CRM forms](/docs/entities/crm-forms). The new routes use REST v3: `POST /v1/crm-forms`, `PATCH /v1/crm-forms/:id`, `POST /v1/crm-forms/validate`, `POST /v1/crm-forms/:id/validate`, `POST /v1/crm-forms/:id/activate`, `POST /v1/crm-forms/:id/deactivate`, `DELETE /v1/crm-forms/:id`. Validation supports READONLY keys; writes require READWRITE and the `crm` scope. Updates require `updatedTime` from GET; deleting an active form requires `confirm=true`. Creation returns 201; other successful operations return 200, including validation with `valid:false`. ### NEW-1023-14: CRM form embedding and connected places The Vibecode API provides CRM form embedding codes and its public URL through `GET /v1/crm-forms/:id/embedding`. The `variant` parameter selects `inline`, `click` or `auto`. `PATCH /v1/crm-forms/:id/embedding` saves button and automatic display settings against the form version `updatedTime` and returns reread data. The write changes the form version. `GET /v1/crm-forms/:id/site-buttons` and `GET /v1/crm-forms/:id/openlines` return one page of all site widgets and Open Channels in the account with a `bound` flag for the selected form, including unbound places. Reads require the `crm` scope and support READONLY; writes require READWRITE. ### NEW-1023-15: Company method permissions and readiness Company credentials now check each Bitrix24 method against the current consent and reject the whole batch if any method is not approved. Connection readiness accepts any approved Bitrix24 scope, including `user`, without requiring `crm`. The extra READONLY restriction is removed; the available HTTP routes remain unchanged. ### FIX-1023-16: Deploy after interrupted package installation **Before** Deployment of Node.js 20, Node.js 24 and Python 3.12 applications stopped if system package installation had been interrupted. **After** Deployment automatically attempts to finish package configuration and continues after successful recovery within the existing time limit. ### FIX-1023-17: models fetched with a standard provider key are bound to that key **Before** [POST /v1/ai/credentials/:id/fetch-models](/docs/ai/credentials/fetch-models) saved a standard provider's models (OpenAI, Anthropic, Google Gemini, OpenRouter and others) into the shared platform catalog. Every user with a key of the same provider saw them, and a repeated fetch brought retired platform catalog models back into service. **After** Models of any provider are bound to the key they were fetched with, as Custom keys already worked. They are visible and callable only with that key, appear in [GET /v1/ai/credentials/:id/models](/docs/ai/credentials/models-list) and get the `DEPRECATED` status once the provider stops returning them. Fetching never changes the platform catalog. **Impact on integrators** No action required. To call a standard provider's model with your own key, fetch the catalog with that key via `fetch-models`. One key holds at most 1000 models: when new models do not fit, the response carries the new `truncated: true` field. A key model takes over the capabilities (`capabilities`) of the same-id platform catalog model, so calls with `response_format` and embeddings keep working. ### FIX-1023-18: consistent model selection for personal and company keys `GET /v1/models`, `GET /v1/models/:id`, `POST /v1/chat/completions` and `POST /v1/embeddings` now prefer a personal model over a model with the same ID from a company key or the platform catalog. Model lists, including `GET /v1/me`, count each ID once. Embeddings no longer select another user's key-bound model: when no accessible model exists, the response is `404 ai_model_not_found` instead of the incorrect `402 ai_credentials_not_configured`. No integration changes are required. ### FIX-1023-19: Model replacement metadata uses the platform catalog **Before** The replacement price and `replaced_by` field in `GET /v1/models/{id}`, and the `Link` and `X-Model-Replacement` headers in `POST /v1/chat/completions`, could refer to a model available only through a customer key. **After** This replacement metadata is published only for models in the platform catalog. If an old reference points to a customer-key model, the model detail keeps its own price without `replaced_by`, and replacement headers are omitted.