Apideck list endpoints use cursor pagination, not page numbers

Not specified by the original author.

TL;DR: Use the SDK helpers (for await...of in Node, .next() in Python/Go/.NET) instead of hand-rolling cursors. Web (Apideck official best-practices skill, apideck-libraries/api-skills): documents pagination gotchas agents hit. Apideck uses cursor-based pagination on all list endpoints: iterate until meta.cursors.next is null, never assume one page returns everything. limit is 1-200 with default 20, so large syncs need bigger pages.

Web (Apideck official best-practices skill, apideck-libraries/api-skills): documents pagination gotchas agents hit. Apideck uses cursor-based pagination on all list endpoints: iterate until meta.cursors.next is null, never assume one page returns everything. limit is 1-200 with default 20, so large syncs need bigger pages. Use the SDK helpers (for await...of in Node, .next() in Python/Go/.NET) instead of hand-rolling cursors. For incremental sync, use filter[updated_since] with an ISO 8601 timestamp to fetch only changed records. Narrow server-side with filter and fields params; do not fetch everything and filter client-side.

What to do

Paginating Apideck list calls: always loop on meta.cursors.next until it is null, and set limit up to 200 so you are not crawling at 20 records a page. Use the SDK pagination helpers instead of manual cursor plumbing. For sync jobs, combine filter[updated_since] with a stored timestamp so each run only pulls changed records, and pass fields to request only the columns you need. Fetching full records and filtering client-side wastes quota and breaks at scale.

When to use

You hit exactly this: Apideck list endpoints use cursor pagination, not page numbers in Apideck.

When not to use

A different error, or the same symptom in a different tool. This page only covers the failure above.

Compatibility

Apideck.

Web (Apideck official best-practices skill, apideck-libraries/api-skills): documents pagination gotchas agents hit. Apideck uses cursor-based pagination on all list endpoints: iterate until meta.cursors.next is null, never assume one page returns everything. limit is 1-200 with default 20, so large syncs need bigger pages. Use the SDK helpers (for await...of in Node, .next() in Python/Go/.NET) instead of hand-rolling cursors. For incremental sync, use filter[updated_since] with an ISO 8601 timestamp to fetch only changed records. Narrow server-side with filter and fields params; do not fetch everything and filter client-side.

Verified answer: Paginating Apideck list calls: always loop on meta.cursors.next until it is null, and set limit up to 200 so you are not crawling at 20 records a page. Use the SDK pagination helpers instead of manual cursor plumbing. For sync jobs, combine filter[updated_since] with a stored timestamp so each run only pulls changed records, and pass fields to request only the columns you need. Fetching full records and filtering client-side wastes quota and breaks at scale.

Source: https://github.com/neversight/learn-skills.dev/blob/HEAD/data/skills-md/apideck-libraries/api-skills/apideck-best-practices/SKILL.md