Pagination & batch limits
Two page styles, one cap of 50, and two batch endpoints that truncate silently — chunk client-side.
Vault style — top-level fields#
GET /vault paginates with top-level fields. limit defaults to the maximum, 50:
{
"items": [ … ],
"folders": [ … ],
"hasMore": true,
"total": 132,
"page": 1,
"limit": 50
}Posts style — nested pagination#
GET /posts nests the same information under pagination. limit defaults to 20 and caps at 50:
{
"posts": [ … ],
"pagination": { "page": 1, "limit": 20, "total": 47, "hasMore": true },
"limits": { … }
}A page can legitimately come back shorter than limit while more items remain. The only correct loop is: request page 1, then keep incrementing page while hasMore is true.
What does not paginate#
- Folders — GET /vault/folders returns every folder, unpaginated.
- Earnings transactions — GET /earnings always returns the 50 most recent transactions in the range; narrow the date range to see older ones.
Batch caps — truncation is silent#
Two endpoints take arrays of ids and silently drop the excess — no error, no truncated flag:
| Endpoint | Cap |
|---|---|
| POST /vault/video-status | 50 ids per call |
| POST /drops/check-status | 200 ids per call |
Chunk client-side: send at most the cap per request and merge the result maps. Both endpoints also omit ids they cannot resolve (see Errors), so never treat a missing key as a transport failure.
Next: Moderation & statuses or Errors.
Questions? [email protected]