API changes: July 11, 2026

← Changelog · July 2026

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 answered with a bare 502 GALAXY_HOST_UNREACHABLE, and a slot created in one call via POST /v1/infra/servers 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) — 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.

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) 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 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.