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

[← Журнал изменений](/docs/changelog) · [Август 2026](/docs/changelog/2026-08)

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

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

**Было**

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

**Стало**

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

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

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

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

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

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

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

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

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

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

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

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

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

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