API changes: August 30, 2026

← Changelog · August 2026

BC-0830-1: Presigned single-PUT upload is temporarily disabled

Old format supported until: not provided

Before

Path B minted a presigned PUT URL for single-PUT uploads and published it through /complete.

After

Path B (URL creation and completion) now fails closed with 503 STORAGE_PRESIGNED_UPLOAD_DISABLED. Use direct upload (Path A) or multipart upload (Path C) for new writes; legacy PENDING reservations are neither published nor automatically released by GC.

BC-0830-2: an application rename no longer reports success without confirmation from Bitrix24

Old format supported until: not provided

Before

On a developer-key rename PATCH /v1/apps/{id} removed the previous menu-item binding and created a new one. When Bitrix24 rejected the new binding after a confirmed removal, the response was 502 BITRIX_PARTIAL_REBIND and the item stayed removed.

On the cloud OAuth path the same method behaved differently in another case: when Bitrix24 confirmed neither the removal of the previous binding nor the new one, the response was 200 OK with a warning and the new name was saved. The menu item either disappeared from the account or kept its previous label, and a repeated request no longer rebound it, because the platform considered the name current.

After

On a developer-key rename the platform makes one attempt to restore the previous label. Successfully restored placements are listed in the new error.restored field and need no manual repair. The error.unbound field lists the placements to check on the account: those left removed, plus those whose removal Bitrix24 never confirmed. The new error.bitrixCodes and error.bitrixStatuses fields carry sanitised diagnostics for every rejected call.

The cloud OAuth path now answers 502 BITRIX_PARTIAL_REBIND and does NOT save the new name when Bitrix24 confirmed neither the removal nor the new binding.

What integrators should do

Treat 502 BITRIX_PARTIAL_REBIND as "the name was not saved" and repeat the request — a retry fires the rebind again. The former 200 OK did not mean success in this scenario. Only the placements in error.unbound need manual restoration through POST /v1/placements/bind.

FIX-0830-3: for `bitrix/*` models a stream that never started also ends with a retryable error

Before

When the upstream of a bitrix/* model sent no response headers, the platform silently repeated the request and waited for another full budget. The client received nothing meanwhile — up to two full budgets of silence — and then saw a generic provider failure that does not tell a stalled stream setup apart from any other unclassified error.

data: { "error": { "code": "ai_provider_unavailable", "type": "server_error", "retryable": true, "retryAfter": 6 } }
data: [DONE]

After

Stream setup for these models makes a single attempt on one shared budget. If the headers do not arrive within it, the wait no longer doubles and the stream ends with the same stream_idle_timeout event as a stream that went silent mid-response — naming the stream itself as the thing that stalled.

data: { "error": { "code": "stream_idle_timeout", "type": "server_error", "retryable": true, "retryAfter": 7 } }
data: [DONE]

The wait no longer doubles invisibly and the reason is named precisely. Models from other providers are not affected yet: their stream setup still takes two attempts and ends with the generic ai_provider_unavailable.