Skip to content

Pagination

The list endpoints for alerts, audit logs, teams, and users return results in pages. This page explains how to ask for a page and how to fetch the next one.

Invites and API keys are not paginated. Those lists are small, so one request returns all of them.

ParameterDescription
limitMaximum number of items in a page. Optional.
idThe cursor for the next page. Pass the value from the previous response’s pk.

limit can be any whole number from 1 to 100.

Anything else (zero, a negative number, a number over 100, a decimal, or text) is treated as 20.

EndpointDefault when limit is omitted
Alerts20
Audit logs20
Teams20
UsersNo default. Without limit, the response contains as many users as fit in one page.

A list response has these fields:

FieldDescription
itemsThe items in this page
pkThe cursor for the next page. Treat it as opaque. It is only present when more results exist.
  1. Make the first request, with or without limit.
  2. If the response has no pk, you have the last page. You’re done.
  3. If the response has pk, repeat the same request and add the pk value as a query parameter. For example, pass id=<pk.id>.
  4. Keep the same limit and other parameters on every request.
  5. Repeat until a response has no pk.

The user list uses a cursor with two values. The pk holds a username and an email. To get the next page, pass both as query parameters: username=<pk.username> and email=<pk.email>. Passing only one of them doesn’t work.

These endpoints also accept:

ParameterDescription
orderSet to asc for oldest first. Any other value, or no value, returns newest first.
startThe earliest time to include. The bound is inclusive.
endThe latest time to include. The bound is inclusive.

Use start and end to filter by time. You can use either one alone, or both together. The unit depends on the endpoint:

  • Audit logs: epoch milliseconds.
  • Alerts: epoch microseconds.

Teams are sorted by ID, lowest first. The team list does not support order.