Pagination

List endpoints are cursor-paginated. There is no page number and no total count — cursors are stable under insertion and deletion, which page numbers are not.

Parameters

Response envelope

{
  "data": [ { "object": "user", "id": "user_1", "…": "…" } ],
  "has_more": true,
  "next_cursor": "user_1"
}

When has_more is false, next_cursor is null and you have reached the end.

# First page
curl "https://api.atlas.dev/v1/users?limit=100" \
  -H "Authorization: Bearer sk_live_xxx"

# Next page
curl "https://api.atlas.dev/v1/users?limit=100&starting_after=user_1" \
  -H "Authorization: Bearer sk_live_xxx"

Some list routes (memberships, roles, permissions, invitations by org) use a lighter { "object": "list", "data": [...], "has_more": … } envelope without a cursor, because the sets are small and bounded.

Walking every page with an SDK

The Node SDK ships paginate (an async generator) and collect (the whole set), which work with any cursor-paginated list:

import { paginate, collect } from '@atlas/backend';

// Stream users one at a time
for await (const user of paginate(atlas.users.list)) {
  console.log(user.id);
}

// Or gather them all
const orgs = await collect(atlas.organizations.list);

The Ruby, Python, Go, and other SDKs expose the same walk (Atlas.paginate / paginate(...)). Prefer streaming for large sets so you make extra round trips only when you actually need the next page.