Изменения API: 17 августа 2026

← Журнал изменений · Август 2026

FIX-0817-1: повторный деплой PostgreSQL-рантайма не падает на существующей базе

Было

POST /v1/infra/servers/:id/deploy с одним из PostgreSQL-рантаймов при повторном запуске пытался снова создать базу app, и шаг установки рантайма мог завершиться ошибкой.

Стало

Рантаймы node20-pg, node20-pg-redis, node20-rag, python311-pg и python311-rag создают базу app только при её отсутствии. Настоящая ошибка создания по-прежнему останавливает деплой.

Влияние на интеграторов

Повторный деплой с тем же PostgreSQL-рантаймом не требует ручного удаления базы или смены рантайма.

FIX-0817-2: справочник статистики звонков показывает рабочие фильтры и сортировку

Было

Машинная подсказка для GET /v1/calls/statistics предлагала несуществующие поля диапазона дат и не объясняла, что поле сортировки и направление передаются отдельно.

Стало

Подсказка и OpenAPI показывают сравнения filter[>CALL_START_DATE] / filter[<CALL_START_DATE], пару sort + order и фактическую одностраничную пагинацию до 50 записей. Соседние операции управления звонками теперь также используют реальные пути с :callId и фактические тела запросов для регистрации, завершения, расшифровки, автообзвона и обратного звонка.

Влияние на интеграторов

Используйте канонические операторы Bitrix24 в ключах фильтра и передавайте направление сортировки отдельным параметром order.

FIX-0817-3: выдача ключа деплоя Cowork/Code возвращает флот, потерянный прежними выдачами

Было

POST /v1/cowork/deploy-key переносил связи на свежий ключ только с того ключа, который активен на момент выдачи. Всё, что осталось на ключах, отозванных раньше, под перенос не попадало: серверы не возвращались в GET /v1/infra/servers ни при одной последующей выдаче, отвечали 404 на запрос по адресу и 403 WRONG_KEY на публикацию. Если действующего ключа деплоя у владельца не было вовсе, выдача не переносила ничего — то есть повторный запрос ключа такую потерю тоже не лечил. Оставался только ручной путь: привязка сервера к действующему ключу в кабинете.

Стало

Выдача забирает связи со всех ранее отозванных проектных ключей того же владельца и портала, а не только с текущего действующего — до пяти ключей за вызов, начиная с самого свежего. Владение серверами, карточка приложения, живые токены доступа и область видимости операций деплоя переезжают на свежий ключ в той же транзакции, что и сама выдача, поэтому список серверов и публикация работают сразу после ответа. Случай «действующего ключа нет» больше не особый: связи переносятся и на первую выдачу.

Влияние на интеграторов

Менять ничего не нужно. Оговорка прошлой правки о том, что потерянное возвращается только вручную через кабинет, снята — достаточно запросить ключ ещё раз. Если связей накопилось больше, чем на пяти ключах, остаток заберут следующие выдачи; ключ живёт семь дней, поэтому отдельного действия это не требует.

NEW-0817-4: компенсации квоты видны в ответах подписки Cowork/Code

GET /v1/cowork/me и GET /v1/cowork/state отдают блок relief — отметки о том, когда поддержка платформы Вайбкод сбрасывала счётчики расхода и когда выдавала временное увеличение лимитов. Обе отметки приходят с точностью до часа и видны 7 суток, дальше поле пустое. Вместе с блоком сводка по подписке начала отдавать boostPct и boostExpiresAt — размер и срок действующего увеличения, которые до этого были только в полном состоянии.

Пустое relief.boostGrantedAt не означает, что увеличения нет: отметка нужна для разового уведомления и живёт 7 суток, а само увеличение выдают на срок до 30 суток. Действует увеличение или нет, показывает только boostPct.

Возможность включается по аккаунтам. Пока она не включена, всех перечисленных ключей нет в теле ответа вовсе, поэтому проверяйте наличие ключа, а не его значение. Прежние вызовы работают без изменений.

NEW-0817-5: словарь типов уведомлений

Появился GET /v1/notifications/schema — справочник модулей портала и типов уведомлений, которые они отправляют. Параметров у операции нет.

Ответ несёт массив modules, у каждого модуля идентификатор, название и список типов. Идентификатор модуля совпадает с полем notifyModule уведомления в ленте, идентификатор типа — с notifyEvent, поэтому справочник закрывает задачу «показать человеку понятное название вместо технического кода» и годится для экранов настройки уведомлений.

Битрикс24 отдаёт справочник картой, ключ которой повторяет идентификатор модуля внутри записи, — API Вайбкод разворачивает её в массив. Порядок элементов приходит от портала и контрактом сортировки не является. Состав справочника зависит от портала и меняется с обновлениями Битрикс24, поэтому ответ стоит кэшировать, но перечитывать при встрече незнакомого модуля или типа.

NEW-0817-6: настройки календаря портала доступны через API

Добавлен эндпоинт GET /v1/calendar/settings — он возвращает настройки календаря Битрикс24: начало и конец рабочего дня, выходные дни недели, праздники, рабочие субботы и первый день недели. Это те же значения, по которым интерфейс Битрикс24 размечает нерабочие дни. Параметров у запроса нет, нужен ключ со скоупом calendar.

Фиксированные поля ответа приходят в camelCase — workTimeStart, weekHolidays, yearHolidays. Адреса разделов для нестандартных типов календаря приходят по одному полю на тип, с именем в том виде, в каком его отдаёт портал, поэтому набор полей ответа не фиксирован.

Владельцу ключа, который не является сотрудником портала, Битрикс24 отдаёт сокращённый набор из двух полей со значениями по умолчанию вместо настроек портала. По самим значениям такой ответ от настроенного портала не отличается, поэтому в него добавляется meta.warnings с кодом calendar_settings_partial.

У эндпоинта есть собственный лимит — 120 запросов в минуту на портал, помимо общего лимита обращений к Битрикс24. Настройки меняются редко, поэтому ответ рассчитан на кэширование на стороне клиента, а не на частый опрос.

События и разделы календаря по-прежнему доступны как сущности — /v1/calendar-events и /v1/calendar-sections.