Pagination and filtering

Read stable cursor pages and apply only the filters an endpoint supports.

Cursor pagination

Collection endpoints use opaque AMLOK cursors. The default page size is 100, with a minimum of 1 and maximum of 200.

GET /v1/bank-transactions?subject_id=biz_example&posted_from=2026-09-01&posted_to=2026-10-01&limit=100

Read page.next_cursor and send it with the same filters on the next request. Finish when page.has_more is false and page.next_cursor is null. Do not decode a cursor or substitute an upstream provider cursor.

Resource collections use stable updated_at, then id ordering. The credit ledger instead uses ascending sequence with its documented sequence_after filter. Cursors bind the workspace, institution, filters, and snapshot. A cursor from a different query or environment must be rejected.

// Node.js, using your institution-issued environment and key.
const baseUrl = process.env.AMLOK_API_BASE_URL;
const apiKey = process.env.AMLOK_API_KEY;
if (!baseUrl || !apiKey) throw new Error("Configure API environment and key");
const seen = new Set();
let cursor;
let finished = false;
for (let pageNumber = 0; pageNumber < 1000; pageNumber++) {
  const url = new URL("/v1/bank-transactions", baseUrl);
  url.search = new URLSearchParams({
    subject_id: "biz_example", posted_from: "2026-09-01",
    posted_to: "2026-10-01", limit: "100", ...(cursor ? { cursor } : {})
  }).toString();
  const response = await fetch(url, {
    headers: { Authorization: `Bearer ${apiKey}`, Accept: "application/json" },
    redirect: "error", signal: AbortSignal.timeout(30000)
  });
  if (!response.ok) throw new Error(`HTTP ${response.status}`);
  const result = await response.json();
  // Persist/process result.data; also inspect result.meta.data_status and coverage.
  if (!result.page.has_more) { finished = true; break; }
  cursor = result.page.next_cursor;
  if (!cursor || seen.has(cursor)) throw new Error("Invalid or repeated cursor");
  seen.add(cursor);
}
if (!finished) throw new Error("Client page budget reached; save progress for review");

The 1,000-page budget is an example client safeguard. It is not a server limit. Add your retry policy around each request and persist the continuation state if processing spans runs.

Filters are endpoint-specific

Common resource filters include subject_id, updated_from, and updated_to. Source-backed collections can expose connection_id; resources with a status can expose a typed status filter. Each endpoint page lists the supported parameters.

Specialized filters include bank-account and posting-date filters, invoice due dates, loan days-past-due thresholds, lien jurisdiction, and attribute key. Unsupported or unknown parameters return 400 instead of silently broadening the result.

Intervals are start-inclusive and end-exclusive unless the individual field explicitly says otherwise. Unknown source dates do not match a dated filter.

Historical reads and changes

as_of is supported only for stored point-in-time attribute or risk-snapshot results. It is not a universal historical-read parameter. Billing uses an immutable snapshot_id instead: obtain it from the current billing snapshot, then reuse it across financial reads and exports. Cursor pages remain bound to the same snapshot and filters.

Use the change feed for normalized created, updated, and deleted actions. Keep its cursor separate from collection cursors and source-adapter cursors. Create a synchronization checkpoint before collection bootstrap and resume changes from its cursor. Every change response includes a durable resume cursor and explicit expiry, including empty pages. See reliable synchronization.