API changes: August 16, 2026

← Changelog · August 2026

NEW-0816-1: the app icon accepts raster files, and a Bitrix24 account can push one itself

The icon upload POST /v1/infra/servers/:id/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.

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

In your Vibecode account the icon picker narrowed the other way: the server card and the application card take PNG, JPG, GIF and WEBP, and now refuse SVG — that format stays in the API alone.

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

NEW-0816-2: two fields describing a temporary limit increase in the Cowork/Code state

The GET /v1/cowork/state 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.

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

NEW-0816-3: new 402 company_budget_exhausted rejection on calls that spend credits

Before

The only money-related rejection on /v1/search/* and on AI calls was insufficient funds on the account — INSUFFICIENT_BALANCE. An administrator had no way to cap the spend of an individual employee or of the whole account.

After

An account administrator can set a monthly budget for metered spend — for the whole account and for an individual employee. Once the budget is exhausted, web search and research calls, as well as AI calls — POST /v1/chat/completions, POST /v1/embeddings and POST /v1/audio/transcriptions — that spend credits receive a 402 with the code company_budget_exhausted.

The rejection body carries two extra fields. scope tells whose budget is exhausted: USER is the caller's own budget, PORTAL is the budget of the whole account. canRequest tells whether an increase can be requested from the product: true for a personal budget, false for the account budget, which only an administrator raises.

The rejection is returned only on calls that actually spend credits: a search made with the customer'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.

Budgets are enabled separately and are off by default, so accounts without them see no change.

FIX-0816-4: the Cowork deploy-key handout no longer loses servers

Before

POST /v1/cowork/deploy-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 /v1/infra/servers, answered 404 on a direct read and 403 WRONG_KEY on deploy. The only way back was the dashboard.

After

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

The read scope of started operations moves with them, so GET /v1/infra/operations/{operationId} 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".

Impact on integrators

Nothing to change: from this fix onward a re-issue no longer loses the links.

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.

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