Skip to main content

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:
integer
default:20
Number of items to return per pageRange: 1-100 itemsDefault: 20 items
string
Cursor for fetching the next page of resultsUse the after value from the previous response to get the next page
string
Cursor for fetching the previous page of resultsUse the before value from the previous response to get the previous page
string
Field to order results byAvailable fields depend on the endpoint (e.g., created, domain, name)
string
default:"asc"
Sort directionValues: asc (ascending) or desc (descending)Default: asc

Response Structure

All paginated responses follow this structure:

Response Fields

integer
The number of items per page requested
string | null
Cursor to fetch the next page of resultsnull if there are no more pages
string | null
Cursor to fetch the previous page of resultsnull if this is the first page
boolean
Indicates whether there are more items after the current pageUse this to determine if you should fetch the next page
array
Array of items for the current page

Paginated Endpoints

The following endpoints support pagination:
  • GET /agents - List team members
  • GET /monitors - List DNS monitors
  • GET /monitors/{monitor_uuid}/events - List events for a monitor
  • GET /groups - List monitor groups
  • GET /groups/{slug}/monitors - List monitors in a group
  • GET /webhooks - List webhooks
  • GET /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 the after cursor from the response to fetch the next page:

Sorting Results

You can control the sort order of results using order_by and order_way parameters:
Use the before 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

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
Always check the has_more field to avoid unnecessary requests:
Empty result sets are valid and should be handled gracefully:
Save the after cursor to resume pagination later:
The actual number of items returned may be less than the requested limit, even if more pages exist:
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

Don’t Manipulate Cursors: Cursors are opaque tokens. Never try to decode, modify, or construct them manually. Always use the values provided by the API.
Don’t Use Offset-Based Logic: Unlike offset-based pagination, you cannot jump to arbitrary pages (e.g., “page 5”). You must iterate sequentially using cursors.
Cursors Can Expire: Cursors may become invalid after extended periods. If you receive an error, restart pagination from the beginning.

See Also