# API changes: August 9, 2026

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

### BC-0809-1: meta.total is no longer returned by default in lists

> Old format supported until: 09.02.2027

**Before**

[GET /v1/{entity}](/docs/entity-api) and [POST /v1/{entity}/search](/docs/entity-api) sent `meta.total` — the number of records matching the filter — unless the request declined the count explicitly. Declining was possible with the `withTotal=false` parameter or the `totalDefault` setting on the key, but the platform default meant "count", so an integration that knew nothing about counting always received the number.

**After**

The platform default changed to "do not count": the count is now ordered explicitly. There are three ways to ask for it, and they override one another in this order: the `withTotal=true` request parameter (on `POST /v1/{entity}/search` it is the body field `"withTotal": true`), the `totalDefault` setting on the API key, and the platform default.

If the number was not asked for, the presence of `meta.total` follows the shape of the call:

| Call | `meta.total` |
|---|---|
| `limit` at most 50, `offset` 0, page shorter than requested | arrives, exact number — `0` included |
| `limit` at most 50, full page or `offset` above zero | absent |
| `limit` above 50 | arrives |

A short page proves the count by itself, so the exact number arrives for free and no count is ordered. On a call with `limit` above 50 the platform needs the count to plan the walk, so the number arrives as it used to — passing `withTotal=false` there buys nothing: the parameter removes the number, not the cost.

An explicit `withTotal=false` removes the key on any of these calls: behind that parameter the "no such field" promise stays unconditional. The `totalDefault` setting on the key and the platform default do not forbid the exact number a short page proves, so two identical requests from two different keys can come back in different shapes.

All of this applies to calls where the count can be skipped. Where it cannot, `withTotal=false` is ignored and `meta.total` arrives as before. Check for the field in the response at hand rather than deriving it from the key settings.

The new default also applies to list sub-calls inside [POST /v1/batch](/docs/batch): there the number arrives in `data.totals` and `meta` under the call id, and it is absent by the same rules.

The rest of the response is unchanged: `data` holds the same records in the same order, and `meta.hasMore` is still there and still tells you whether more pages remain.

**What integrators should do**

If your code reads `meta.total`, pick one of two options.

Once, for the whole integration — turn on the `totalDefault` setting on the API key: the keys page in the dashboard, or [PATCH /v1/keys/:id](/docs/management-keys) with the body `{"totalDefault": true}` (a `vibe_live_` management key). No code change needed.

Per call — add `withTotal=true` to the calls that genuinely need the number: `GET /v1/deals?withTotal=true`, or `"withTotal": true` in the search body.

What applies to your key right now is shown by the `totalDefault` block in [GET /v1/me](/docs/keys-auth/me): `key` is the key setting, `platform` is the platform default, and `effective` is what you get when the request sends no `withTotal`.

Separately: if `meta.total` was your paging loop bound, switch to `meta.hasMore` — that is more reliable either way. And if you needed the number itself, ask for it directly: `POST /v1/{entity}/aggregate` with the `count` function returns the count in one call. Do not walk the collection page by page just to get a counter — that is dozens of calls instead of one.