[{"data":1,"prerenderedAt":7},["ShallowReactive",2],{"docs-changelog\u002F2026-07-11":3,"docs-tabs-changelog\u002F2026-07-11":6},{"content":4,"lastmod":5},"# API changes: July 11, 2026\n\n[← Changelog](\u002Fdocs\u002Fchangelog) · [July 2026](\u002Fdocs\u002Fchangelog\u002F2026-07)\n\n### FIX-0711-1: galaxies: GALAXY_HOST_UNREACHABLE is now actionable — structured hint and a precise provisionError\n\n**Before**\n\nWhen a galaxy host was temporarily unreachable, [POST \u002Fv1\u002Finfra\u002Fservers\u002F:id\u002Fdeploy](\u002Fdocs\u002Finfra\u002Fdeploy\u002Fdeploy) answered with a bare 502 `GALAXY_HOST_UNREACHABLE`, and a slot created in one call via [POST \u002Fv1\u002Finfra\u002Fservers](\u002Fdocs\u002Finfra\u002Fservers\u002Fcreate) 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.\n\n**After**\n\nThe 502 `GALAXY_HOST_UNREACHABLE` response — on deploy, exec and delete ([DELETE \u002Fv1\u002Finfra\u002Fservers\u002F:id](\u002Fdocs\u002Finfra\u002Fservers\u002Fdelete)) — 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 \u002Fv1\u002Finfra\u002Fservers\u002F:id\u002Fsources](\u002Fdocs\u002Fsource-storage).\n\n**Impact on integrators**\n\nThe 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.\n\n### NEW-0711-2: distinct error code when the Vibecode Connector module is not installed in the Bitrix24 account\n\nIssuing an application key through the connector module ([POST \u002Fv1\u002Fapps](\u002Fdocs\u002Fapps)) 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.\n\n### FIX-0711-3: GET \u002Fv1\u002Fai\u002Fquota pacing can now be populated by the platform by default (gradual rollout)\n\nThe platform can now enable pacing (AI-quota day\u002Fweek 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 \u002Fv1\u002Fai\u002Fquota](\u002Fdocs\u002Fai\u002Fconsumption\u002Fquota) 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.\n",null,{},1794739470401]