API changes: October 23, 2026

← Changelog · October 2026

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 and DELETE /v1/infra/servers/:id 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 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 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_<id>, 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 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.

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
• GET /v1/bots/:botId/events
• GET /v1/bookings/:id/clients
• GET /v1/booking-wait-list/:id/clients
• GET /v1/calendar-resources/bookings
• GET /v1/calendar/accessibility
• GET /v1/catalog-products/:productId/images
• GET /v1/chats/events
• GET /v1/chats/:dialogId/users
• GET /v1/chats/recent
• GET /v1/crm-deliveries
• GET /v1/crm-documents
• GET /v1/crm-payments/:id/products
• GET /v1/crm-payments/available-products
• GET /v1/humanresources/nodes/:id/children
• GET /v1/humanresources/nodes/:id/communications
• GET /v1/infra/servers/:id/b24-users
• GET /v1/mail/mailboxes/:id/senders
• GET /v1/mail/messages/:id/thread
• GET /v1/me/workgroups
• GET /v1/note/collections
• GET /v1/note/collections/:collectionId/documents
• GET /v1/note/documents
• GET /v1/note/documents/search
• GET /v1/openline-configs/:lineId/quick-replies
• GET /v1/openlines/crm/chats
• GET /v1/openlines/operators
• GET /v1/posts
• GET /v1/scrum/epics
• GET /v1/scrum/sprints
• GET /v1/scrum/sprints/:sprintId/stages
• GET /v1/stage-history
• GET /v1/tasks/:taskId/chat/messages
• GET /v1/tasks/:taskId/dependencies
• GET /v1/timeline-logs
• GET /v1/triggers
• GET /v1/workday/time-control/reports
• GET /v1/workday/time-control/users
• GET /v1/workgroups/:groupId/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, 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 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 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 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 endpoint.

FIX-1023-12: Calendar event and section batch lists forward required parameters

Before

The list action in POST /v1/calendar-events/batch and POST /v1/calendar-sections/batch 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. 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 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 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.