[{"data":1,"prerenderedAt":7},["ShallowReactive",2],{"docs-changelog\u002F2026-08-16":3,"docs-tabs-changelog\u002F2026-08-16":6},{"content":4,"lastmod":5},"# API changes: August 16, 2026\n\n[← Changelog](\u002Fdocs\u002Fchangelog) · [August 2026](\u002Fdocs\u002Fchangelog\u002F2026-08)\n\n### NEW-0816-1: the app icon accepts raster files, and a Bitrix24 account can push one itself\n\nThe icon upload [POST \u002Fv1\u002Finfra\u002Fservers\u002F:id\u002Ficon](\u002Fdocs\u002Finfra\u002Fapp-icon) now accepts raster formats — PNG, JPG, GIF, WEBP, up to 5 MB and up to 4 megapixels (2000×2000, for example) — in addition to SVG. The format is detected from the file contents, not from its name or its `Content-Type` header. Whatever you upload, the serve URL still returns a 256×256 PNG: the platform scales the image into a square, keeping its proportions and padding the rest with transparency. Existing SVG uploads keep working unchanged: the SVG limits — 256 KB and the same 4096×4096 ceiling as before — are untouched.\n\nNew refusal codes: `ICON_UNSUPPORTED_FORMAT` for a format that is unrecognized or unsupported, `ICON_TOO_LARGE` for a file above the size limit, `ICON_TOO_MANY_PIXELS` for an image with more pixels than the platform will unpack, `ICON_RASTERIZE_FAILED` for a file that cannot be read.\n\nThe other half of the change is on the Bitrix24 side: an app owner can now replace the icon straight from the Bitrix24 catalog card, and Bitrix24 pushes it to the Vibecode platform together with the title and the description. That icon lands on the same catalog card as one uploaded through the API.\n\n### NEW-0816-2: two fields describing a temporary limit increase in the Cowork state\n\nThe [GET \u002Fv1\u002Fcowork\u002Fstate](\u002Fdocs\u002Fcowork\u002Fstate) response now carries two fields describing a temporary limit increase: `boostPct` — the increase in percent (100 means limits are doubled), and `boostExpiresAt` — when it ends. With no increase active they read `0` and `null`.\n\nThe `pctUsed` shares of all three windows already account for the increase, so there is nothing to apply on the client side — the fields exist so you can show the size and the deadline to the user.\n\n### NEW-0816-3: new 402 company_budget_exhausted rejection on calls that spend credits\n\n**Before**\n\nThe only money-related rejection on `\u002Fv1\u002Fsearch\u002F*` and on AI calls was insufficient funds on the account — `INSUFFICIENT_BALANCE`. An administrator had no way to cap the spend of an individual\nemployee or of the whole account.\n\n**After**\n\nAn account administrator can set a monthly budget for metered spend — for the whole account and for\nan individual employee. Once the budget is exhausted, web search and research calls, as well as AI calls — [POST \u002Fv1\u002Fchat\u002Fcompletions](\u002Fdocs\u002Fai\u002Fchat\u002Fcompletions), [POST \u002Fv1\u002Fembeddings](\u002Fdocs\u002Fai\u002Fembeddings) and [POST \u002Fv1\u002Faudio\u002Ftranscriptions](\u002Fdocs\u002Fai\u002Faudio\u002Ftranscriptions) — that spend credits receive a `402` with\nthe code `company_budget_exhausted`.\n\nThe rejection body carries two extra fields. `scope` tells whose budget is exhausted: `USER` is the\ncaller's own budget, `PORTAL` is the budget of the whole account. `canRequest` tells whether an\nincrease can be requested from the product: `true` for a personal budget, `false` for the account\nbudget, which only an administrator raises.\n\nThe rejection is returned only on calls that actually spend credits: a search made with the\ncustomer's own key costs nothing and keeps working when the budget is exhausted, and so do AI calls made with the customer's own key, calls served inside the plan quota, and calls covered by a subscription. A call already in flight is completed: the limit applies from the next request.\n\nBudgets are enabled separately and are off by default, so accounts without them see no change.\n\n### FIX-0816-4: the Cowork deploy-key handout no longer loses servers\n\n**Before**\n\n[POST \u002Fv1\u002Fcowork\u002Fdeploy-key](\u002Fdocs\u002Fcowork\u002Fdeploy-key) revoked the previous key but left everything that referenced it behind: server ownership, the application card and live access tokens. Versioned infrastructure reads are scoped to the calling key, so after every re-issue the earlier servers dropped out of `GET \u002Fv1\u002Finfra\u002Fservers`, answered `404` on a direct read and `403 WRONG_KEY` on deploy. The only way back was the dashboard.\n\n**After**\n\nThe handout moves those links onto the fresh key, exactly as key rotation does. The server list and deploy work under the new key straight away, containers on a shared galaxy host included.\n\nThe read scope of started operations moves with them, so [GET \u002Fv1\u002Finfra\u002Foperations\u002F{operationId}](\u002Fdocs\u002Finfra\u002Fdeploy\u002Foperation-status) keeps returning the outcome of a run begun under the previous key. A client whose transport dropped — and which therefore asked for a new key — used to get `404` on its own operation, indistinguishable from \"no such operation\".\n\n**Impact on integrators**\n\nNothing to change: from this fix onward a re-issue no longer loses the links.\n\n**Important:** the fix works forward and **does not recover what is already lost**. The move starts from the key that is active at handout time, while orphaned links sit on keys revoked earlier, so they are outside its reach. If your servers disappeared before this rollout, restore them by hand: in the Vibecode dashboard, open the server card and bind it to the key you use now.\n\nThe key lives for seven days and is not re-issued on a schedule. If it goes untouched for longer, the servers stay with the expired key and become visible again after the next handout, which moves the links off it.\n",null,{},1794739475249]