# API changes: September 6, 2026 [← Changelog](/docs/changelog) · [September 2026](/docs/changelog/2026-09) ### FIX-0906-1: a free Bitrix24 plan now answers key issuance terminally, not with a "retry later" **Before** A cloud account on a free Bitrix24 plan could get 502 `CONNECTOR_REST_UNAVAILABLE` with `details.retryable: true` on key issuance, whenever its Marketplace access read as in force. The answer promised that a retry would help. Bitrix24 shuts REST off entirely on a free plan, so a retry never did. The `activation.marketTrial.available` flag in `GET /v1/cowork/state` has always read `false` on this segment: the Marketplace trial is a subscription-region product, so `POST /v1/cowork/activate-market-trial` never had a one-time trial to spend here. **After** The same case answers terminally with the refusal this segment already uses for a plan that does not carry access — `INT_TARIFF_REQUIRED` (403) with a `userMessage` naming the remedy, a paid Bitrix24 plan. The code is not new; what changed is the set of states it comes in: previously only "access paid for but not in force", now any access state on a plan read as free. A retry without changing the plan returns the same thing. `activation.marketTrial.available` keeps its `region_not_supported` reason on this segment, and `POST /v1/cowork/activate-market-trial` together with `POST /v1/portals/{id}/activate-market-trial` keep refusing exactly as before — that half of the change is region-gated above the plan check and does not reach here. An account on the Bitrix24 demo plan is not affected either: that plan does not shut REST off, so it keeps the answer it had. An account whose plan could not be read behaves as before. ### BC-0906-2: PATCH /v1/infra/servers/:id/mode rejects opening a server with a sealed role > Old format supported until: not provided **Before** For a server whose role (a pool member, a service machine) requires a sealed network policy, [PATCH /v1/infra/servers/:id/mode](/docs/infra/access/mode) with `mode: "OPEN"` responded `200`: the server did switch to open mode, and the issued SSH password worked. **After** Such a request is now rejected with `409 MODE_SWITCH_SEALED_ROLE`; the server's mode is left unchanged and no password is issued. The rejection applies where the server's network policy is backed by the additional layer for that server; where it is not backed, behavior is unchanged. **What integrators should do** Clients that expected `200` for servers with a sealed role must handle `409 MODE_SWITCH_SEALED_ROLE` as a terminal rejection: open mode is not available for such a server, and retrying will not help. For other servers (not a sealed role), `200` and password issuance are unchanged. ### NEW-0906-3: PATCH /v1/infra/servers/:id/mode may return a network-policy switch failure [PATCH /v1/infra/servers/:id/mode](/docs/infra/access/mode) enforces a server's network policy with one more layer — outside the guest machine, on top of the protection already in place inside it. If switching the server's network policy fails, the endpoint responds `503 SECURITY_GROUP_ATTACH_FAILED`; the server's mode is left unchanged, and retrying the request makes sense. This rejection is only possible where the additional layer is supported for a given server; where it is not supported, the endpoint's behavior is unchanged. ### FIX-0906-4: PATCH /v1/infra/servers/:id/mode closes the server firewall when the connection drops mid-switch **Before** [PATCH /v1/infra/servers/:id/mode](/docs/infra/access/mode) performs the switch by running commands on the server itself. If the connection was lost partway through that sequence — a timeout, a dropped tunnel, an unreachable agent — the endpoint returned an error, but the server could be left with its firewall already open while its mode stayed `BLACKHOLE`: the opening command had time to run, and nothing was left to close it again. The error, meanwhile, reported that the switch had been aborted. **After** Such a drop now triggers closing the firewall back before the error reaches the client: previously nothing was attempted on this path, and a server left open while its mode said `BLACKHOLE` stayed that way until someone intervened. That closing travels over the same connection that has just dropped, so it is an attempt, not a guarantee: if the server is unreachable altogether it does not arrive either, and the discrepancy remains. The response does not report this — the outcome of the attempt is visible in the platform log. One case is deliberately left out: if the server had already been closed and it was the mode write that failed, the firewall is NOT reopened — undoing a completed closure because of a write failure would be the more dangerous choice. The server is then closed while its mode is reported as `OPEN`. **What integrators should do** Response codes are unchanged, and retrying the request still makes sense. In the exception described above, retrying with `mode: "OPEN"` is rejected as `400 SAME_MODE` — the stored mode is already `OPEN`; access is restored by switching to `BLACKHOLE` and back to `OPEN`. ### BC-0906-5: a platform integration key now dies together with its issuer's authority > Old format supported until: 31.12.2026 **Before** A `/v1/platform/*` key lived until someone revoked it by hand. Revoking a team member's platform tier, blocking them, or accepting an account-erasure request left the key alone: the revenue export channel and coupon batches kept working on behalf of a person the platform itself no longer admits. **After** The key is revoked automatically at the moment its creator loses platform authority — tier revocation, a block, or an accepted erasure request. Requests made with such a key receive `401`. The remaining platform administrators get an email listing the revoked keys. If the channel is still needed, issue a new key from an active team member: `POST /api/platform/integration-keys`. There is no way to check the channel state in advance — the email is the notification — so integrations should treat `401` as "a new key is required" rather than as a transient error.