Overview
The Explorium API supports two pagination modes for the Fetch Businesses (POST /v1/businesses) and Fetch Prospects (POST /v1/prospects) endpoints:
| Mode | Best For | Max Results |
|---|---|---|
| Offset-based (page / page_size) | Small to medium datasets, random page access | Up to 60,000 records |
| Cursor-based (search_after) | Large datasets, streaming all results efficiently | No limit |
Offset-Based Pagination
Offset-based pagination usespage and page_size parameters to retrieve specific pages of results. This is the simplest approach and works well when you need random access to any page.
Parameters
| Parameter | Type | Required | Description |
|---|---|---|---|
size | Number | No | Maximum total records to return across all pages. Defaults to 60,000. Must be ≤ 60,000. |
page_size | Number | Yes | Number of records per page. Maximum: 500. |
page | Number | No | Page number to retrieve (1-based). Defaults to 1. |
How It Works
- Send your first request with
page: 1and your desiredpage_size. - The response includes
total_results,total_pages, andpageso you know how many pages are available. - Increment
pageto retrieve subsequent pages until you reachtotal_pages.
Example Request
Example Response
Full Python Example
Cursor-Based Pagination (Search After)
Cursor-based pagination uses an opaquenext_cursor token to iterate through results sequentially. This mode is more efficient for large datasets because it avoids the performance overhead of deep page offsets.
Parameters
| Parameter | Type | Required | Description |
|---|---|---|---|
page_size | Number | Yes | Number of records per page. Maximum: 100. |
next_cursor | String | Yes | Cursor token from a previous response. Omit or set to null for the first request. |
When using cursor-based pagination, the
size parameter is optional and ignored. The response will return the true total_results count regardless of any size value provided.How It Works
- Send your first request with
next_cursorset tonull. - The response includes a
pageobject withsize(number of records returned) andnext_cursor. - Pass the
next_cursorvalue from the response into your next request. - Repeat until
next_cursorisnull, which indicates you’ve reached the last page.
Example Request — First Page
Example Response — First Page
Example Request — Next Page
Pass thenext_cursor from the previous response:
Example Response — Last Page
When there are no more results,next_cursor is null:
Full Python Example
Response Format Comparison
The response structure differs slightly depending on which pagination mode you use.- Offset-Based Response
- Cursor-Based Response
| Field | Type | Description |
|---|---|---|
total_results | Number | Total matching records (capped by size). |
page | Number | Current page number. |
total_pages | Number | Total number of pages available. |
Choosing the Right Mode
Use Offset-Based When
- You need to jump to a specific page number.
- Your result set is small to medium (under ~10,000 records).
- You want to display a page selector UI (e.g., “Page 3 of 12”).
- You need to know the total page count upfront.
Use Cursor-Based When
- You’re iterating through all results sequentially.
- Your result set is large (10,000+ records).
- You want consistent performance regardless of how deep you paginate.
- You need the true
total_resultscount independent of thesizeparameter.
Best Practices
Always set page_size explicitly
Always set page_size explicitly
While
page_size has a default, setting it explicitly (recommended: 100) ensures predictable response sizes and makes your code easier to reason about.Handle the last page gracefully
Handle the last page gracefully
The last page of results will often contain fewer records than
page_size. In offset mode, check page >= total_pages. In cursor mode, check next_cursor == null.Don't mix pagination modes
Don't mix pagination modes
Use either
page (offset-based) or next_cursor (cursor-based) in a given request — not both. If next_cursor is provided, the API uses cursor-based pagination and the page parameter is ignored.Cursor tokens are opaque
Cursor tokens are opaque
Treat
next_cursor values as opaque strings. Don’t attempt to parse, modify, or construct them. Always use the exact value returned by the API.Keep filters consistent across pages
Keep filters consistent across pages
When paginating through results (in either mode), always send the same
filters and mode parameters with each request. Changing filters mid-pagination will produce inconsistent results.Implement retry logic
Implement retry logic
For large pagination jobs, implement retry logic with exponential backoff in case of transient errors. Save the last successful
next_cursor or page number so you can resume without re-fetching.Supported Endpoints
Both pagination modes are available on the following endpoints:| Endpoint | Method | Path |
|---|---|---|
| Fetch Businesses | POST | /v1/businesses |
| Fetch Prospects | POST | /v1/prospects |