All Nexla API listing endpoints support paginated queries to limit the number of response objects and set the start position of the returned array of objects. This is specially useful in case of endpoints for metrics, notifications, and other monitoring events where the size of total set of records might make fetching full list in one call inefficient.

These paginated queries are also a good way to use Nexla API monitoring events as a source of data in Nexla.

Use query parameters page and per_page on any endpoint that supports pagiantion. For example: /data_source?page=2&per_page=10 fetches sources 11 to 20 when all sources in user's account are sorted by the default order. Note that these pagiantion parameters work in conjunction with any other query filtering paramters supported on the endpoint.

Responses to paginated queries contain a response header named Link which has a link to Previous and Next page of response. Note that absence of Previous signifies the response is the first page of data (i.e. no previous page available). Similaerly, absence of Next signifies the response is the last page of data (i.e. no more pages available).

For example, in the request below, we are fetching 11th to 20th oldest error notifications for source id 6889.

Sample Paginated Query: Request
GET /notifications?resource_type=SOURCE&resource_id=6889&level=ERROR&page=2&per_page=10
Sample Paginated Query: Response Header
Note: This is only a snippet of response headers:
link →< URL/notifications?resource_type=SOURCE&resource_id=6889&level=ERROR&page=1&per_page=10>; rel="Previous", <URL/notifications?resource_type=SOURCE&resource_id=6889&level=ERROR&page=3&per_page=10>; rel="Next"
X-Total-Count : 10
X-Current-Page : 2
X-Page-Count : 1