# API changes: October 22, 2026

[← Changelog](/docs/changelog) · [October 2026](/docs/changelog/2026-10)

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

**Before**

[POST /v1/infra/servers/:id/deploy](/docs/infra/deploy/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](/docs/infra/lifecycle/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](/docs/infra/servers/get).

### 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](/docs/infra/app-runtime) and [What is safe to retry](/docs/errors/retry-safety).

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

> Old format supported until: not provided

**Before**

After [DELETE /v1/keys/:id](/docs/management-keys) 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](/docs/partner-connect)
and the `data` object from [GET /v1/connect/company/status](/docs/partner-connect)
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.