Overview
The Moflay API uses cursor-based pagination for all list endpoints. This approach provides several advantages over traditional offset-based pagination:- Consistent results - No duplicate or missing items when data changes during pagination
- Performance - Efficient for large datasets with proper database indexing
- Reliability - Works well even when items are added or removed between requests
How Cursor Pagination Works
Cursor pagination uses a “cursor” (a pointer to a specific position in the dataset) rather than an offset. The cursor is a base64-encoded value that points to the last item from the previous page, based on thecreatedAt
field for consistent ordering.
Basic Flow
- First Request - Make a request without a cursor to get the first page
- Subsequent Requests - Use the
cursor
from the previous response to get the next page - Last Page - When
hasNextPage
isfalse
, you’ve reached the end
Pagination Parameters
All list endpoints support these query parameters:Parameter | Type | Required | Default | Description |
---|---|---|---|---|
cursor | string | No | - | Base64-encoded cursor for pagination, representing the last item from the previous page |
limit | integer | No | 10 | Number of items to return (1-100) |
Example Request
Example Response
Getting the Next Page
To get the next page, use thecursor
value from the previous response:
End of Results
When you’ve reached the last page, the response will have:Sorting and Pagination
All list endpoints support sorting, which affects the pagination order:- Default sorting - Most endpoints default to
createdAt
in descending order (newest first) - Custom sorting - Use
sortBy
andsortOrder
parameters to customize - Consistent ordering - The same sort parameters must be used across all pages
- Cursor basis - The cursor is always based on the
createdAt
field for reliable pagination
Example with Sorting
Filtering and Pagination
Filters can be combined with pagination. The same filters must be applied to all pages:Best Practices
1. Use Appropriate Limit Values
- Small datasets - Use smaller limits (5-20) for better performance
- Large datasets - Use larger limits (50-100) to reduce API calls
- Real-time updates - Use smaller limits for more frequent updates
2. Handle Rate Limits
- Implement exponential backoff when you receive
429
responses - Consider the rate limits when choosing your pagination strategy
3. Error Handling
- Always check for
hasNextPage
before making the next request - Handle cases where the cursor might be invalid or expired
- Implement retry logic for transient failures
4. Caching Considerations
- Cursors are not stable across API versions
- Don’t store cursors for long periods
- Refresh cursors if you encounter errors
Common Patterns
Iterating Through All Results
Processing in Batches
Troubleshooting
Invalid Cursor Error
If you receive an error about an invalid cursor:- Check cursor format - Ensure the cursor is properly URL-encoded
- Verify cursor source - Make sure you’re using the cursor from the correct endpoint
- Handle expired cursors - Start pagination from the beginning if cursors are too old
Empty Results
If you get empty results buthasNextPage
is true:
- Check filters - Verify your filter parameters are correct
- Verify permissions - Ensure your API key has access to the data
- Check date ranges - Verify your date filters are appropriate
Performance Issues
If pagination is slow:- Reduce limit - Try smaller page sizes
- Add indexes - Ensure your database has proper indexes for sorting
- Check filters - Complex filters can impact performance