[{"data":1,"prerenderedAt":7},["ShallowReactive",2],{"docs-changelog\u002F2026-08-30":3,"docs-tabs-changelog\u002F2026-08-30":6},{"content":4,"lastmod":5},"# API changes: August 30, 2026\n\n[← Changelog](\u002Fdocs\u002Fchangelog) · [August 2026](\u002Fdocs\u002Fchangelog\u002F2026-08)\n\n### BC-0830-1: Presigned single-PUT upload is temporarily disabled\n\n> Old format supported until: not provided\n\n**Before**\n\nPath B minted a presigned PUT URL for single-PUT uploads and published it through `\u002Fcomplete`.\n\n**After**\n\nPath 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.\n\n### BC-0830-2: an application rename no longer reports success without confirmation from Bitrix24\n\n> Old format supported until: not provided\n\n**Before**\n\nOn a developer-key rename [PATCH \u002Fv1\u002Fapps\u002F{id}](\u002Fdocs\u002Fapps\u002Fupdate) 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.\n\nOn 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.\n\n**After**\n\nOn 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.\n\nThe 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.\n\n**What integrators should do**\n\nTreat `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 \u002Fv1\u002Fplacements\u002Fbind](\u002Fdocs\u002Fapps\u002Fplacements\u002Fbind).\n\n### FIX-0830-3: for `bitrix\u002F*` models a stream that never started also ends with a retryable error\n\n**Before**\n\nWhen the upstream of a `bitrix\u002F*` 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.\n\n```\ndata: { \"error\": { \"code\": \"ai_provider_unavailable\", \"type\": \"server_error\", \"retryable\": true, \"retryAfter\": 6 } }\ndata: [DONE]\n```\n\n**After**\n\nStream 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.\n\n```\ndata: { \"error\": { \"code\": \"stream_idle_timeout\", \"type\": \"server_error\", \"retryable\": true, \"retryAfter\": 7 } }\ndata: [DONE]\n```\n\nThe 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`.\n",null,{},1794739477144]