Skip to main content

Overview

All TerraQuake API endpoints that return lists of earthquakes support pagination to help you efficiently retrieve large datasets. Pagination allows you to request data in manageable chunks rather than fetching everything at once.

Pagination Parameters

Use query parameters to control pagination:
integer
default:"1"
The page number to retrieve. Must be a positive integer greater than 0.Example: ?page=2
integer
default:"50"
Number of results per page. Must be a positive integer between 1 and 100.Example: ?limit=25

Default Values

  • Default page: 1 (first page)
  • Default limit: 50 results per page
  • Maximum limit: 100 results per page (hard cap)
If you request a limit greater than 100, the API will automatically cap it at 100 to prevent performance issues.

Pagination Response Format

Paginated responses include a pagination object with metadata about the current page and available data:

Pagination Fields

integer
Current page number
integer
Total number of pages available
integer
Number of results per page (after applying the 100 max cap)
boolean
Whether more pages exist after the current page. Use this to determine if you should fetch the next page.
integer
Total number of earthquake records available (across all pages)

How Pagination Works

The API uses offset-based pagination with manual slicing:
  1. Calculate offset: startIndex = (page - 1) × limit
  2. Calculate end: endIndex = startIndex + limit
  3. Slice data: Return items from startIndex to endIndex
  4. Cap page number: If requested page exceeds totalPages, return the last available page

Implementation Example

From the source code:
Source: /home/daytona/workspace/source/backend/src/utils/processFeatures.js:99-105

Examples

Basic Pagination

Paginating Through All Results

Smart Pagination with Rate Limit Handling

Combining Pagination with Filters

You can combine pagination with other query parameters:

Error Handling

Invalid Page Number

If you request a page less than 1:

Invalid Limit

If you request a limit less than 1:

Page Beyond Available Data

If you request a page number greater than totalPages, the API automatically returns the last available page instead of an error.

Best Practices

Use Appropriate Page Size

Request only what you need. Smaller page sizes (10-25) for UI display, larger (50-100) for data processing.

Check hasMore

Always check the hasMore field to determine if there are more pages, rather than comparing page numbers.

Handle Empty Results

If totalEarthquakes is 0, the payload will be an empty array. Handle this gracefully in your application.

Respect Rate Limits

When paginating through many pages, add delays between requests to avoid hitting rate limits.

Performance Tips

  1. Cache Results: Store fetched pages in memory or a local database to avoid redundant requests
  2. Use Filters: Combine pagination with filters (magnitude, region, date) to reduce the total number of results
  3. Parallel Requests: For non-sequential pages, you can fetch multiple pages in parallel (respect rate limits)
  4. Progressive Loading: For UI applications, load the first page immediately and fetch subsequent pages on-demand

Common Questions

The API validates page numbers and returns a 400 error if the page is less than 1.
No, the API enforces a hard cap of 100 results per page. Requests for higher limits are automatically capped at 100.
Yes, as new earthquakes occur, the total count and number of pages may increase. Results on each page may also shift.
Check if pagination.hasMore is false or if pagination.page === pagination.totalPages.