Pagination

Every list endpoint is offset-paginated and returns the same envelope: a metaobject describing the page, and a results array of records. Readmeta.hasMore to decide whether to fetch the next page — don't infer "done" from a short or empty result set.

The envelope

meta + results
{
  "meta": {
    "limit": 25,
    "offset": 0,
    "hasMore": true
  },
  "results": [
    { "id": "prp_01HX0G5T8N3KEWBYV2QMR4DCFA" }
  ]
}

Note: it's hasMore, camelCase. The fields:

FieldTypeMeaning
meta.limitintegerPage size used for this response.
meta.offsetintegerRecords skipped before this page.
meta.hasMorebooleanWhether more records exist past this page.
resultsarrayThe records for this page.

limit and offset

  • limit — page size. Defaults to 25, maximum 100.
  • offset — how many records to skip. Defaults to 0.

Request a limit above 100 and you'll get a 400 — the value isn't silently clamped. Keep it at or below 100, and use the max for backfills so you make the fewest round trips.

Get a page of 100, starting at record 200
curl "https://api.propsocket.io/v1/units?limit=100&offset=200" \
  -H "Authorization: Bearer ps_test_YOUR_TEST_KEY"

Loop until hasMore is false

The canonical pattern: fetch a page, process it, stop when meta.hasMore isfalse, otherwise advance offset by your page size. The versions below are generators so you can stream through large result sets without holding everything in memory.

Paginate every record
# Page through manually: bump offset by limit until hasMore is false.
curl "https://api.propsocket.io/v1/units?limit=100&offset=0&order-by=created_at:asc" \
  -H "Authorization: Bearer ps_test_YOUR_TEST_KEY"
# ...then offset=100, offset=200, ... until meta.hasMore == false

Sort interaction

Pagination and sorting compose with the order-by query parameter, formattedfield:direction (asc or desc). The default sort iscreated_at:desc.

For any loop that walks the full collection — backfills, reconciliation, warehouse loads — sort by created_at:asc. New records always append to the end, so an ascending walk by creation time never shifts the records you've already paged past. Sorting descending (the default) means a new insert lands at offset 0 and pushes everything down by one, which can cause you to re-read or skip a record across page boundaries.

Anti-pattern: parallel offsets

It's tempting to speed up a backfill by firing requests foroffset=0, offset=100, offset=200 all at once. Don't. The underlying collection is live — a record inserted (or soft-deleted) between two of those requests shifts the window, so adjacent pages can overlap or leave a gap. You'll silently duplicate or drop records.

Page sequentially, sorted by created_at:asc, and dedupe on the record's stableid if you must parallelize at a higher level (e.g., one worker per entity type). For throughput planning under the rate limit, see rate limits.

Next

Narrow what you page through with filtering, or see the full list response shapes in the API reference.