Pagination

List endpoints use cursor-based pagination. Each response includes a pagination object:

{
  "data": [
    /* items */
  ],
  "pagination": {
    "next_cursor": "eyJpZCI6IjAxSjkifQ==",
    "has_more": true
  }
}

Use cursors when you sync bookmarks, folders, or other collections that can grow beyond a single response. Do not invent page numbers — the server encodes position in next_cursor.

Prerequisites

A valid API key or JWT (Authentication).
The list endpoint path and required headers (often X-Workspace-ID for workspace resources).
Client code that loops while pagination.has_more is true.

Requesting a page

Query parameter	Type	Default	Notes
`cursor`	string	—	Pass the `next_cursor` from the previous response
`limit`	integer	50	Max 200

Example (set N24M_API_KEY to your workspace API key in the shell first):

curl --url 'https://api.not24get.me/workspaces/WS/bookmarks?limit=100' \
     --header "Authorization: Bearer ${N24M_API_KEY}" \
     --header 'X-Workspace-ID: WS'

Then for the next page:

curl --url 'https://api.not24get.me/workspaces/WS/bookmarks?limit=100&cursor=eyJpZCI6IjAxSjkifQ==' \
     --header "Authorization: Bearer ${N24M_API_KEY}" \
     --header 'X-Workspace-ID: WS'

When pagination.has_more is false, you have reached the end. next_cursor will be null or absent.

Stable ordering

Items are ordered by descending creation time, then by ID for tiebreakers. Cursors include both, so a page never shifts mid-iteration even if new items are created while you paginate.

Don't compute total counts

The API does not return a total row count by default. Counting is expensive and rarely useful in real integrations. If you need an exact count, iterate fully — but consider whether your UX really needs it.

Troubleshooting

Repeating the same page — you omitted cursor or reused an old cursor after changing filters. Always pass the latest next_cursor unchanged.
Missing items at the end — stop only when has_more is false. Do not stop on an empty data array alone if has_more is still true.
400 validation_error on cursor — the cursor is corrupted, truncated, or from a different endpoint/filter set. Restart from the first page.
429 while syncing — lower limit concurrency and respect Rate limits.
Need error shape details — see Errors.

When this helps

Cursor pagination is the right fit for sync jobs, backups, and UI infinite scroll. Keep the cursor opaque: never decode it in client code. If filters change mid-sync, discard the cursor and start over from the first page so you do not skip or repeat rows. Pair large syncs with rate-limit aware clients so a long crawl does not trip 429 responses halfway through the collection.