API changes: September 6, 2026

← Changelog · September 2026

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