Overview
The DNSRadar API uses cursor-based pagination for all list endpoints. This approach provides consistent results even when data is being modified, making it ideal for reliable data synchronization and iteration.Cursor-based pagination ensures you never miss items or see duplicates, even if data changes between requests.
Pagination Parameters
All paginated endpoints accept the following query parameters:Number of items to return per pageRange: 1-100 itemsDefault: 20 items
Cursor for fetching the next page of resultsUse the
after value from the previous response to get the next pageCursor for fetching the previous page of resultsUse the
before value from the previous response to get the previous pageField to order results byAvailable fields depend on the endpoint (e.g.,
created, domain, name)Sort directionValues:
asc (ascending) or desc (descending)Default: ascResponse Structure
All paginated responses follow this structure:Response Fields
The number of items per page requested
Cursor to fetch the next page of results
null if there are no more pagesCursor to fetch the previous page of results
null if this is the first pageIndicates whether there are more items after the current pageUse this to determine if you should fetch the next page
Array of items for the current page
Paginated Endpoints
The following endpoints support pagination:GET /agents- List team membersGET /monitors- List DNS monitorsGET /monitors/{monitor_uuid}/events- List events for a monitorGET /groups- List monitor groupsGET /groups/{slug}/monitors- List monitors in a groupGET /webhooks- List webhooksGET /webhooks/{uuid}/requests- List webhook execution requests
Basic Pagination
Fetching the First Page
To get the first page of results, simply call the endpoint without any cursor parameters:Fetching the Next Page
Use theafter cursor from the response to fetch the next page:
Sorting Results
You can control the sort order of results usingorder_by and order_way parameters:
Navigating Backwards
Use thebefore cursor to navigate to the previous page:
The
before cursor is useful for implementing “Previous” buttons in pagination UI or for backward navigation in your application.Best Practices
Use Appropriate Page Sizes
Use Appropriate Page Sizes
Choose page sizes based on your use case:
- Small pages (10-20): Good for UI display, faster response times
- Medium pages (50): Balanced for most applications
- Large pages (100): Efficient for bulk processing, fewer API calls
Check has_more Before Fetching
Check has_more Before Fetching
Always check the
has_more field to avoid unnecessary requests:Handle Empty Results
Handle Empty Results
Empty result sets are valid and should be handled gracefully:
Store Cursors for Resumption
Store Cursors for Resumption
Save the
after cursor to resume pagination later:Don't Assume Fixed Page Sizes
Don't Assume Fixed Page Sizes
The actual number of items returned may be less than the requested limit, even if more pages exist:
Respect Rate Limits
Respect Rate Limits
When iterating through all pages, respect rate limits by adding delays:
Complete Example: Paginated Export
Here’s a complete example of exporting all monitors to a CSV file:Common Pitfalls
See Also
- Rate Limiting - Understanding API rate limits when paginating
- Error Codes - Handling pagination errors
- API Reference - Detailed endpoint documentation

