Pagination

List endpoints return a page of records. Read each endpoint's parameters and response: some resources support both cursor directions, while others support forward continuation only.

Use an SDK iterator

This example reads email records with the JavaScript SDK. The API key needs emails:read permission.

import { Epostix } from '@epostix/sdk';

const apiKey = process.env.EPOSTIX_API_KEY;
if (!apiKey) throw new Error('Set EPOSTIX_API_KEY');

const client = new Epostix({ apiKey });

for await (const email of client.emails.listEmailsIterate({ limit: 100 })) {
  console.log(email.id, email.status);
}

The iterator requests subsequent pages as needed. Handle a rejected iteration just as you would another SDK call; an error is not the end of a successful list.

Cursor parameters

Parameter	Meaning
limit	Page size; use the range and default documented for the endpoint
starting_after	Continue after the supplied cursor
ending_before	Move backward, on endpoints that support it

Do not pass both cursor directions in one request. Treat cursors as opaque values and keep the same filters while continuing a list.

For responses with has_more and next_cursor, continue with the returned cursor while more records are available. Do not compute a cursor from the last ID unless the endpoint explicitly documents that contract. An empty or short page alone is not a reliable continuation rule.

Changing data

Cursor pagination avoids the positional shifts of page-number offsets. It does not freeze the dataset. New records, deletions and changing filter values can affect what is visible during a long traversal.

For a repeatable export or reconciliation job, choose a time boundary where the endpoint supports one and deduplicate by record ID in your own system.