Recover a Complete Crossref Result Set with Cursors

Save each page as an explicit retrieval step

For a large Crossref query, fix the filters, requested fields, sorting, and page size. Begin cursor-based pagination using cursor=* and a positive page size such as rows=100. Pass the returned next-cursor value as the cursor for the following request, with normal URL encoding. A cursor is an opaque service value. Store page status, request time, item count, and a local page identifier with each response.

Write a page successfully before advancing the checkpoint. If a request fails, inspect the response and service instructions before retrying. Treat a repeat fetch as a retry of the same logical page and deduplicate by the work identifier before emitting results. A cursor may expire, so keep enough query information to restart a bounded retrieval interval.

Inspect a hypothetical retry

A query yields pages containing 100, 100, and 37 records. A retry saves the second page twice. The raw page files contain 337 rows, while the intended three pages contain 237 records. If identifiers are unique across the intended pages, grouping by identifier yields 237 distinct works. A discrepancy after that check requires examination of overlapping pages or a changing index.

Stop when the returned item count falls below the requested page size or the service ends the cursor sequence. An empty final page also satisfies the count rule. Save the evidence of termination. Save the complete query and retrieval window with the distinct identifier manifest. Reporting an API's displayed total without checking the saved pages leaves gaps and duplicate writes invisible.

Crossref REST API retrieval guidance

Related worksheet: Systematic review search-run worksheet.

Source checked on 5 November 2026.