# API changes: August 17, 2026

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

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

**Before**

[POST /v1/infra/servers/:id/deploy](/docs/infra/deploy/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](/docs/telephony/analytics/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](/docs/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](/docs/infra/servers/list), 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](/docs/cowork/me) and [GET /v1/cowork/state](/docs/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](/docs/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](/docs/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`.