# API changes: August 30, 2026

[← Changelog](/docs/changelog) · [August 2026](/docs/changelog/2026-08)

### 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}](/docs/apps/update) 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](/docs/apps/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`.