API changes: October 21, 2026

← Changelog · October 2026

NEW-1021-1: python312 runtime on Python 3.12 from the Ubuntu 24.04 archive

The GET /v1/infra/runtimes catalog adds the python312, python312-pg, python312-mysql, python312-redis and python312-rag runtimes. On a dedicated virtual machine Python 3.12 comes from the Ubuntu 24.04 archive, and the app's packages live in a separate platform environment: the python, pip and pip3 commands run in it, while python3 and python3.12 stay the system interpreter without the app's packages. So for python312* write python app.py in the start field, not python3 app.py. In Galaxy the runtime is built from the official python:3.12-slim image, where both commands work. The python311* runtimes stay in the catalog and work as before.

BC-1021-2: Neutral image identifiers and names

Old format supported until: not provided

Before

GET /v1/infra/providers/:providerId/images could return internal OS build identifiers and names.

After

For Bitrix24 Cloud images that previously returned an internal build identifier, id now contains the ubuntu-2404-lts family and name is Ubuntu 24.04 LTS. The response remains HTTP 200 with the same fields. Other image values are unchanged.

What integrators should do

Pass the returned data[].id as image when creating a server. Do not infer the OS from the internal identifier format or parse the name string. Previously returned identifiers remain accepted when creating a server.

NEW-1021-3: APP_DB_BUSY reports that the galaxy host is starting

The 409 APP_DB_BUSY response to an application database read gains an optional details.hostState field. It equals waking while the galaxy host is starting after sleep or creation, and is absent when the host is busy with another operation. The field arrives in responses of GET /v1/infra/servers/{id}/db, GET /v1/infra/servers/{id}/db/schema, GET /v1/infra/servers/{id}/db/tables/{table}/rows and POST /v1/infra/servers/{id}/db/query. The error code, Retry-After and the retryable flag stay the same: retry the request as before and show the user that the server is starting.

FIX-1021-4: an oversized request to a model: images for bitrix are downscaled, a size refusal is 413 instead of 502

Before

POST /v1/chat/completions with a bitrix/* model and a body over the model cluster limit answered 502 ai_provider_unavailable, the same as a model failure. Repeating the same request got 502 again. Other AI methods, for example POST /v1/embeddings and POST /v1/audio/transcriptions, answered the same 502 instead of a size refusal when the provider itself refused the request by size.

After

When the body contains data: images and exceeds the limit, the platform downscales them itself and sends the request to the model. A body still over the 2 MiB limit after that gets 413 ai_payload_too_large, and the message states the request size and the limit in effect. When the platform is already downscaling many images at once, the response is 429 ai_image_resize_busy with a Retry-After header. The request is not sent to the model and nothing is charged. With stream: true both refusals arrive as an error frame with the same code inside a 200 response, and the pause for ai_image_resize_busy arrives as the retryAfter field of the frame. When the provider itself refused the request by size, any AI method, models on your own provider key included, answers 413 ai_payload_too_large with providerStatusCode: 413. Image downscaling and the check before the model call apply only to chat with bitrix/* models.

Impact on integrators

Requests within the limit work as before. Requests with large images go through with no change on the client side. Retrying a 413 will not help, after a 429 retry after Retry-After, in a stream after retryAfter from the error frame. To control the quality yourself, downscale images to 1500 pixels on the long side. Details — image analysis.

NEW-1021-5: Connector catalog groups, session modes and metadata

Connector list GET /v1/connectors accepts group=all|connected|own|available and mode=cowork|code. Selection happens before pagination. connected contains entries with a connection, available contains the remaining visible entries, and own is currently empty. Group counts apply the other filters except group and view. Start at the first page when changing group or mode; omitted group and all share cursors. Supplier session mode does not change the access policy read/write mode.

Service-company and publisher fields match the card: service-company data includes the supplier-provided name and URL, or null when absent; publisher includes its name and URL. The required categories field contains nonempty visible catalog categories before search, filters and pagination, including responses without list parameters. sort=popular uses the number of companies with an active connection, excluding internal Bitrix24 accounts; counts refresh daily. Explicit pages include tool counts and popularity indicators. Connected connectors do not receive a popularity badge.

FIX-1021-6: The Deploy API operation limit is counted per API key and server

Before

Requests with no key, an invalid key or another valid key consumed a shared server counter. The owner could therefore receive 429 RATE_LIMITED even when making very few requests to the server. This affected POST /v1/infra/servers/:id/exec, POST /v1/infra/servers/:id/upload, POST /v1/infra/servers/:id/deploy, POST /v1/infra/servers/:id/icon and GET /v1/infra/servers/:id/logs.

After

The counter is kept separately for each API-key-and-server pair. Requests with no key or an invalid key do not consume the owner's limit. Another valid key uses its own counter. The threshold is unchanged: the effective value is returned in the x-ratelimit-limit header.

Impact on integrators

No integration changes are required. When your key exceeds its own threshold, the response still contains 429 RATE_LIMITED in the same format. Retry the request after the interval specified in the Retry-After header.

FIX-1021-7: Request and response examples in the API reference

Before

Some examples showed invented response fields or requests rejected by the API. The OAuth instructions suggested opening a URL containing the secret application key in the browser.

After

Examples follow the current handlers. For OAuth sign-in, the application server obtains the authorization URL and the browser opens only the returned URL without the secret key.

Response schemas describe the existing bots, infra and models fields. Template creation keeps server metadata and its download URL, booking fields correctly indicate writability, and the port configuration example uses an allowed application port.

Impact on integrators

Use the updated examples. API behavior is unchanged. Keep the secret application key on the server.

FIX-1021-8: OpenAPI describes the fields for creating a time entry

Before

The body schema for POST /v1/tasks/{taskId}/time advertised commentText, dateStart, and dateStop, which the handler does not save, and did not mark seconds as required.

After

The schema describes required seconds and optional comment, userId, and createdDate. The createdDate field accepts YYYY-MM-DD and ISO 8601 with or without a time zone offset. Request handling is unchanged: the description now matches the fields already supported. Regenerating a client from OpenAPI gives it these field names and required seconds.

FIX-1021-9: bot registration promises a retry only where it helps

Before

POST /v1/bots and POST /v1/bots/registrations/{code}/recover answered any refusal caused by the registration state with HTTP 409 and a Retry-After: 5 header, even when a retry could not help. The error.code field could carry an internal code that the documentation does not describe.

After

The codes described for POST /v1/bots keep their code and text. BOT_REGISTRATION_CONTEXT_CHANGED and BOT_REGISTRATION_PROJECTION_CONFLICT no longer carry Retry-After. BOT_EFFECT_DESIRED_STATE_NOT_PROVED carries Retry-After: the time until the next scheduled check when the registration is waiting for it, otherwise 30 seconds. On BOT_RECOVERY_IN_PROGRESS the header is unchanged. On BOT_DOMAIN_REREGISTRATION_REQUIRED it is unchanged for the response that carries data (a saved bot row kept with the address-move marker); a move detected during the registration itself arrives with the same code but without data and without Retry-After — that refusal is also cleared by a later retry, not by support. Other refusals arrive in public classes. On POST /v1/bots these are BOT_EFFECT_IN_PROGRESS with the same Retry-After rule while the registration is still being reconciled with Bitrix24, and BOT_UNAVAILABLE without Retry-After when the registration state must be repaired by support. On POST /v1/bots/registrations/{code}/recover these are BOT_REGISTRATION_RECOVERY_PENDING with the same Retry-After rule and BOT_UNAVAILABLE without the header. The error.details.registrationRef field stays in both recovery responses. The codes and the header rules are described in the 409 response of both methods in the OpenAPI schema GET /v1/openapi.json?scope=imbot.

Impact on integrators

No action is needed. A client that handles 409 retries when Retry-After is present; the one refusal worth retrying without the header is BOT_DOMAIN_REREGISTRATION_REQUIRED without data — a re-registration already running after an address change. On BOT_UNAVAILABLE, contact support and pass registrationRef when the response carries it.