# API changes: July 11, 2026

[← Changelog](/docs/changelog) · [July 2026](/docs/changelog/2026-07)

### FIX-0711-1: galaxies: GALAXY_HOST_UNREACHABLE is now actionable — structured hint and a precise provisionError

**Before**

When a galaxy host was temporarily unreachable, [POST /v1/infra/servers/:id/deploy](/docs/infra/deploy/deploy) answered with a bare 502 `GALAXY_HOST_UNREACHABLE`, and a slot created in one call via [POST /v1/infra/servers](/docs/infra/servers/create) with `source` moved to an error status with the text "Deploy failed unexpectedly — please retry; details are in the server logs". Neither the cause nor the recovery path was reported — clients deleted the slot and created a new one, which does not help: the fresh slot lands on the same host.

**After**

The 502 `GALAXY_HOST_UNREACHABLE` response — on deploy, exec and delete ([DELETE /v1/infra/servers/:id](/docs/infra/servers/delete)) — carries a structured `error.hint`: the condition is transient, the slot and its data are intact, retry the same request in 1–2 minutes, do not delete the slot. On the create-with-`source` path, `provisionError` now contains the real cause ("Galaxy host … became unreachable during build …") and the same advice to re-send the deploy to the existing slot. Additionally: when several servers work under one OAuth application, a saved source version is no longer lost to a version-numbering conflict — neither on the deploy auto-save nor on an explicit save via [POST /v1/infra/servers/:id/sources](/docs/source-storage).

**Impact on integrators**

The change is additive: response codes and statuses did not change; the `error.hint` field was added and the `provisionError` text became precise. No client updates required; AI agents should read `hint.recovery` — it states exactly what to do.

### NEW-0711-2: distinct error code when the Vibecode Connector module is not installed in the Bitrix24 account

Issuing an application key through the connector module ([POST /v1/apps](/docs/apps)) now returns `409` with code `CONNECTOR_MODULE_NOT_INSTALLED` and a clear "install the module" message when the account has no `vibecodeconnector` module, instead of the previous opaque `502 CONNECTOR_APP_INSTALL_FAILED`. This is a legitimate, permanent state (especially for a self-hosted portal), not a transient failure — retrying will not help, the module must be installed in the account. Other issuance error codes are unchanged.

### FIX-0711-3: GET /v1/ai/quota pacing can now be populated by the platform by default (gradual rollout)

The platform can now enable pacing (AI-quota day/week smoothing) by default for an account — no admin action required. The rollout is staged (pilot accounts → all accounts): until an account falls under the platform default-on, the `data.pacing` field in the [GET /v1/ai/quota](/docs/ai/consumption/quota) response stays `null`, same as before. Once an account is under default-on: `mode: "ignore"` is an informational mode, and `active: false` means window limits do not reject requests (a `429 ai_pacing_limited` rejection is impossible). The response shape is unchanged; integrators who already treat `data.pacing` as an optional field need no changes.