API changes: August 17, 2026

← Changelog · August 2026

FIX-0817-1: repeated PostgreSQL runtime deploy no longer fails on an existing database

Before

POST /v1/infra/servers/:id/deploy with a PostgreSQL runtime tried to create the app database again on a repeated run, so the runtime setup step could fail.

After

The node20-pg, node20-pg-redis, node20-rag, python311-pg, and python311-rag runtimes create the app database only when it is absent. A genuine creation failure still stops the deploy.

Impact on integrators

A repeated deploy with the same PostgreSQL runtime no longer requires deleting the database manually or changing the runtime.

FIX-0817-2: calls statistics reference shows working filters and sorting

Before

The machine-readable hint for GET /v1/calls/statistics suggested non-existent date-range fields and did not explain that the sort field and direction are separate parameters.

After

The hint and OpenAPI show filter[>CALL_START_DATE] / filter[<CALL_START_DATE] comparisons, the sort + order pair, and the actual single-page limit of up to 50 records. The adjacent call-management operations now also use the mounted :callId paths and the actual registration, finish, transcription, auto-call, and callback request bodies.

Impact on integrators

Use canonical Bitrix24 comparison operators in filter keys and pass the sort direction in the separate order parameter.

FIX-0817-3: the Cowork/Code deploy-key mint now recovers a fleet stranded by earlier mints

Before

POST /v1/cowork/deploy-key moved links onto the fresh key only from the key that was active at mint time. Anything left on keys revoked earlier was never picked up: those servers stayed out of GET /v1/infra/servers, answered 404 on a single read and 403 WRONG_KEY on publish. When the owner had no live deploy key at all, the mint moved nothing, so requesting another key did not repair such a loss either. The only remaining path was manual: rebinding the server to a live key in the dashboard.

After

A mint now drains links from every previously revoked project key of the same owner and account, not just the currently live one — up to five keys per call, newest first. Server ownership, the application card, live access tokens and the read scope of deploy operations move onto the fresh key inside the same transaction as the mint itself, so the server list and publishing work immediately after the response. The "no live key" case is no longer special: links are moved on a first mint too.

Influence on integrators

No client change is required. The previous entry's caveat — that a stranded fleet comes back only through a manual rebind in the dashboard — no longer applies; requesting the key again is enough. If links piled up on more than five keys, later mints drain the rest; the key lives for seven days, so this needs no separate action.

NEW-0817-4: quota relief is visible in the Cowork/Code subscription responses

GET /v1/cowork/me and GET /v1/cowork/state now return a relief block — the moments Vibecode platform support last reset the usage counters and last granted a temporary limit increase. Both stamps come to the hour and stay visible for 7 days, after which the field is empty. Along with the block, the subscription summary now returns boostPct and boostExpiresAt — the size and the deadline of an active increase, which were carried by the full state only before.

An empty relief.boostGrantedAt does not mean there is no increase: the stamp is there for a one-off notification and lives for 7 days, while an increase is granted for up to 30 days. Whether an increase applies is told by boostPct, and by nothing else.

The capability is switched on account by account. Until it is on, none of the keys listed above are present in the response body at all, so test for the presence of the key rather than for its value. Existing calls keep working unchanged.

NEW-0817-5: notification type dictionary

GET /v1/notifications/schema is now available — a directory of the Bitrix24 account modules and the notification types they send. The operation takes no parameters.

The response carries a modules array; every module has an identifier, a name and a list of types. The module identifier matches the notifyModule field of a notification in the feed and the type identifier matches notifyEvent, so the directory answers the "show a human a readable name instead of a technical code" task and fits notification-settings screens.

Bitrix24 hands the directory over as a map whose key repeats the module identifier inside the entry, and the Vibecode API unwraps it into an array. The element order comes from the account and is not a sort contract. The contents depend on the account and change as Bitrix24 is updated, so cache the response but re-read it when you meet an unfamiliar module or type.

NEW-0817-6: Bitrix24 account calendar settings are available through the API

A new endpoint GET /v1/calendar/settings returns the Bitrix24 calendar settings: work day start and end, weekly days off, holidays, working Saturdays and the first day of the week. These are the values the Bitrix24 interface uses to mark non-working days. The request takes no parameters and needs a key with the calendar scope.

The fixed response fields arrive in camelCase — workTimeStart, weekHolidays, yearHolidays. Section addresses for non-standard calendar types arrive as one field per type, named exactly as the account returns it, so the response field set is not fixed.

When the key owner is not an employee of the account, Bitrix24 returns a reduced set of two fields carrying default values instead of the account settings. Such a response is indistinguishable by value from a configured account, so it carries meta.warnings with the code calendar_settings_partial.

The endpoint has a limit of its own — 120 requests per minute per Bitrix24 account, on top of the shared request limit to Bitrix24. The settings change rarely, so the response is meant to be cached on the client side rather than polled.

Calendar events and sections remain available as entities — /v1/calendar-events and /v1/calendar-sections.