API changes: October 22, 2026

← Changelog · October 2026

FIX-1022-1: Deployment after server wake waits for readiness

Before

POST /v1/infra/servers/:id/deploy could fail with BOOTSTRAP_PROBE_FAILED while the server was still preparing or temporarily lost its connection.

After

For a deployment that installs a runtime on a dedicated server, readiness checks retry after temporary unreadiness or connection loss within the existing 15-minute preparation budget. A terminal readiness failure still fails the deployment, and its message includes a diagnostic category for the cause.

Impact on integrators

Requests require no changes. JSON and SSE formats and existing error codes are preserved. Retrying readiness checks does not restart runtime installation.

NEW-1022-2: waking a server during a configuration change answers 409 RESIZE_IN_PROGRESS

POST /v1/infra/servers/:id/wake answers 409 RESIZE_IN_PROGRESS while the server's configuration is being changed. Such a server starts on its own once the change finishes, so there is no need to retry the call. Track readiness by polling GET /v1/infra/servers/:id.

BC-1022-3: Black Hole tells a dropped connection to the app from app startup, new code BH_APP_CONNECTION_LOST

Old format supported until: not provided

Before

When the agent connected to the app and the connection dropped before a response, or the response body could not be read in full, the Gateway answered a machine client with 503 BH_APP_STARTING and Retry-After: 3. The response said the app was still starting, although it was running and the request may already have run. The Gateway response carried no request ID, so a support request could not be matched to the platform log.

After

Agent version 1.3.41 and later reports the reason for its refusal to the Gateway. A dropped connection to the app or an unread response body now returns 502 BH_APP_CONNECTION_LOST without Retry-After: the app is running and the request may have run, so no automatic retry is offered. A browser still sees the waiting screen. A failed connection to the app's port still returns 503 BH_APP_STARTING. An agent older than 1.3.41 keeps the previous responses until it is updated. Any response the Gateway substitutes for the app's response now carries an X-Vibe-Request-Id header with the same value the app received. The app external API answers the new code the same way as BH_APP_TIMEOUT — 503 APP_API_UNAVAILABLE.

What integrators should do

Handle 502 BH_APP_CONNECTION_LOST like 504 BH_APP_TIMEOUT: before retrying a write, check the operation's effect by a stable identifier, and expect no Retry-After. If your code branched only on BH_APP_STARTING, add the new code to your handling. When you contact support, quote the X-Vibe-Request-Id value from the response.

More — App runtime and What is safe to retry.

BC-1022-4: deleting the final OAuth key deactivates the app

Old format supported until: not provided

Before

After DELETE /v1/keys/:id for the final OAuth key, the app registration remained active and prevented issuing a new key.

After

Deleting the final OAuth key deactivates the app and allows a new key to be issued. The Bitrix24 registration is removed automatically; this may finish later. Deleting one of several keys preserves the remaining keys and the app registration. The successful response remains HTTP 204 with no body.

What integrators should do

Starting with this release, DELETE may return HTTP 409 with code KEY_REVOCATION_RECOVERY_PENDING or KEY_OPERATION_IN_PROGRESS when deletion has not completed. Update the integration to retry DELETE with a bounded delay only after these codes; the old single-request flow is no longer supported.

NEW-1022-5: Who is connected to a company key

Successful COMPANY responses from POST /v1/connect/token and the data object from GET /v1/connect/company/status now include the connected Bitrix24 account domain and name, plus the current consent holder's name and email. When consent or the holder is unavailable, user is null. Rotation by another administrator does not change the holder. Token and status responses, including errors, are not cached. Route permissions and one-time secret delivery are unchanged.