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

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

BC-0809-1: meta.total в списках больше не приходит по умолчанию

Поддержка старого формата до: 09.02.2027

Было

GET /v1/{entity} и POST /v1/{entity}/search присылали meta.total — количество записей под фильтр — если запрос не отказался от подсчёта явно. Отказаться можно было параметром withTotal=false или настройкой totalDefault на ключе, но умолчание платформы означало «считать», поэтому интеграция, которая про подсчёт ничего не знала, получала число всегда.

Стало

Платформенное умолчание сменилось на «не считать»: подсчёт заказывается явно. Попросить его можно тремя способами, они перекрывают друг друга в этом порядке: параметр запроса withTotal=true (у POST /v1/{entity}/search — поле тела "withTotal": true), настройка totalDefault на API-ключе, платформенное умолчание.

Если количество не попросили, наличие meta.total определяется формой вызова:

Вызов	meta.total
Вызовlimit не больше 50, offset 0, страница короче запрошенного	meta.totalприходит, точное число — в том числе 0
Вызовlimit не больше 50, страница полная либо offset больше нуля	meta.totalне приходит
Вызовlimit больше 50	meta.totalприходит

Короткая страница доказывает количество сама, поэтому точное число приходит бесплатно и подсчёт не заказывается. На вызове с limit больше 50 подсчёт нужен платформе, чтобы спланировать обход, поэтому число приходит как раньше — передавать туда withTotal=false ради экономии незачем: параметр уберёт число, а не стоимость.

Явный withTotal=false убирает ключ на любом из этих вызовов: за этим параметром обещание «поля не будет» остаётся безусловным. Настройка totalDefault на ключе и платформенное умолчание точное число из короткой страницы не запрещают, поэтому два одинаковых запроса от двух разных ключей могут вернуть ответы разной формы.

Всё это относится к вызовам, на которых подсчёт можно пропустить. Там, где пропустить его нельзя, withTotal=false игнорируется и meta.total приходит как раньше. Проверяйте наличие поля в конкретном ответе, а не выводите его из настроек ключа.

Новое умолчание действует и на списочных вызовах внутри POST /v1/batch: там количество приходит в data.totals и meta по идентификатору вызова и отсутствует по тем же правилам.

Остальной ответ не изменился: data — те же записи в том же порядке, meta.hasMore на месте и по-прежнему говорит, есть ли ещё страницы.

Что делать интеграторам

Если код читает meta.total, выберите одно из двух.

Разово и на всю интеграцию — включите на API-ключе настройку totalDefault: страница ключей в кабинете или PATCH /v1/keys/:id с телом {"totalDefault": true} (управляющий ключ vibe_live_). Код менять не нужно.

Точечно — добавьте withTotal=true тем вызовам, которым количество действительно нужно: GET /v1/deals?withTotal=true, в теле поиска "withTotal": true.

Что действует на ваш ключ сейчас, показывает блок totalDefault в GET /v1/me: key — настройка ключа, platform — платформенное умолчание, effective — что получится, если запрос не передаст withTotal.

Отдельно: если meta.total использовался как граница цикла листания, переключитесь на meta.hasMore — так надёжнее в любом случае. А если нужна была именно цифра, спросите её прямо: POST /v1/{entity}/aggregate с функцией count отдаёт количество одним вызовом. Обходить коллекцию постранично ради счётчика не надо — это десятки вызовов вместо одного.