API changes: August 9, 2026

← Changelog · August 2026

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

Old format supported until: 09.02.2027

Before

GET /v1/{entity} and POST /v1/{entity}/search 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: 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 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: 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.