Pagination
The beehiiv API uses pagination to manage large result sets efficiently. We support two pagination methods:
- Cursor-based pagination (recommended)
- Offset-based pagination (deprecated)
Cursor-Based Pagination
Cursor-based pagination provides consistent, efficient navigation through large datasets. It uses opaque cursor tokens to mark positions in the result set.
How It Works
- Use the
cursor
parameter to specify where to start fetching results - Set
limit
to control how many results to return per page (max 100) - The response includes a
next_cursor
for fetching the next page - Use
has_more
to determine if additional pages exist
Request Parameters
Response Format
Default response (optimal performance):
With total count (include_total=true
):
Example Usage
First page:
Next page:
Advantages
- Consistent results: No duplicates or missing items during pagination
- Performance: Efficient for large datasets
- Real-time friendly: Works well when data changes frequently
- No deep pagination issues: Maintains performance regardless of page depth
Total Results (Optional)
By default, cursor-based pagination doesn’t include total counts for optimal performance. You can optionally request total counts:
Request with total count:
Performance considerations:
include_total=false
(default): Optimal performance, no additional database queriesinclude_total=true
: Includes total count but requires an additional COUNT query
Use include_total=true
only when you need to display total counts in your UI (e.g., “Showing 10 of 1,500 results”).
For most pagination use cases, the has_more
field is sufficient.
Offset-Based Pagination (Deprecated)
Offset-based pagination is deprecated and will be removed in a future API version. Please migrate to cursor-based pagination.
Offset-based pagination uses page numbers and limits. While still supported, it has several limitations:
- Page limit: Requests beyond page 100 are blocked
- Consistency issues: Results may shift when data changes
- Performance degradation: Slower for deep pagination
Request Parameters
Response Format
Deprecation Timeline
- Current: All offset pagination requests return deprecation warning headers
- After page 100: Requests return a 400 error with migration guidance
- Future: Complete removal of offset pagination support
Migration Guide
Step 1: Update Your Code
Replace offset pagination parameters:
Step 2: Handle Response Changes
Update your response parsing:
Step 3: Update Pagination Logic
Key Differences
Backward Compatibility
During the transition period:
- Both pagination methods are supported
- Offset requests include deprecation warning headers:
X-Pagination-Warning
: Deprecation noticeX-Pagination-Migration-Guide
: Link to this documentation
- Requests beyond page 100 return a 400 error
Testing Your Migration
- Test cursor pagination: Verify your code handles cursor tokens correctly
- Check error handling: Ensure graceful handling of pagination errors
- Performance testing: Compare performance of cursor vs offset pagination
- Monitor headers: Watch for deprecation warnings in your logs
Best Practices
Cursor Pagination
- Store cursors securely: Treat cursor tokens as opaque strings
- Handle missing cursors: Start from the beginning if cursor is invalid
- Use appropriate limits: Balance between API calls and memory usage
- Cache strategically: Cache results but not cursor tokens
Error Handling
Rate Limiting
Be mindful of rate limits when implementing pagination:
- Respect rate limits: Don’t exceed API rate limits
- Implement backoff: Use exponential backoff for rate limit errors
- Batch wisely: Use appropriate page sizes to minimize requests
Support
If you need help migrating to cursor-based pagination:
- Check our API Reference for endpoint-specific examples
- Review the Rate Limiting documentation
- Contact support if you encounter issues during migration