Ask the API for a list of a given size, and see when one was cut

Six list endpoints on the external API now accept a size, and every list says whether it was truncated instead of looking complete.

Six list endpoints on the external API — session images, packshots, videos, products, sceneries and models — answered with the whole list and took no size. On a real account that meant a single call returning close to 1.8 million characters. /presets was the only route on the surface that accepted a size, so anything built on the API had to remember which route was the exception.

All six now accept maxRecords. A call that names no size receives exactly what it received before, so nothing you have already built changes behaviour.

And every list now says whether it was cut. This is the more important half, because it was not something a caller could work around. All of these lists were already capped, and none of them said so: when the cap bit, the response was still 200, the list still looked complete, and count still equalled its length. A truncated list that looks whole is one an integration reasons over as whole — it concludes a product is absent, an image was never generated, an order produced nothing, and nothing in the response marks that conclusion as unsafe.

Every list response now carries truncated. It is always present and reads false when the list is complete, so you can act on it without checking whether the key exists. count keeps its meaning — the number of rows in the response — and is not the signal: on a saturated list it can exceed the ceiling while truncated is true.

The rows you receive in a cut list are the newest matching rows, not an arbitrary subset, and that holds even where the underlying read spans more than one page.

The video list joins the rest of the content surface. It now honours the acting-account header the same way its neighbours do.